|
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve.
Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right?
Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
|
|
|
|
|
I'm very meticulous about the code I write.
I always use regions, and I use the same regions in the same order in every class. This way I know exactly where code parts are.
Also, all of my class members are listed alphabetically in their regions.
When I see bad code, I schedule it for a refactor. I'm actually sitting here right now refactoring some offshore code. These guys just throw code in anywhere and its annoying and flat out lazy.
Unlike you, my manager is totally on board with me cleaning up the code.
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: I schedule it for a refactor.
Let me put it to you like this, the people running this show have probably never refactored anything in their life. And I seriously doubt they know what that is without googling it.
Jeremy Falcon
|
|
|
|
|
Why are you still there?
If it's not broken, fix it until it is
|
|
|
|
|
Because there are some great people here, but most of them aren't technical at all.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Because there are some great people here,
Kevin is right, IMHO. That's not a good reason to stay on. You'll meet good (technical) people at your new gig - go for it!
/ravi
|
|
|
|
|
You might be right. It's not really fulfilling me on a tech level.
Jeremy Falcon
|
|
|
|
|
Because it's the same everywhere you go.
|
|
|
|
|
Jeremy Falcon wrote: And I seriously doubt they know what that is without googling it.
You'll probably find that they're still no nearer to understanding after they've googled it!
|
|
|
|
|
I see the same problem in a lot of companies with Enterprise development. The biggest problem is not using the right tools for the job, (use the latest fad of the month and rewrite it). OOP is not suited for business applications where databases are involved. refactoring is only needed for sh*tty programmers, good code does not need refactoring.
|
|
|
|
|
pkulek wrote: OOP is not suited for business applications where databases are involved
absolutely false. It may not be suited for every application, but it's well suited for most.
pkulek wrote: good code does not need refactoring.
Not being "good code" isn't the only reason to refactor.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
/ravi
|
|
|
|
|
Having neat code doesn't mean that you have good code. You can always use Code maid to tidy up your code but if it's poorly written, that's not great. Also, how big are you classes that you need to use regions to manage everything? That would set warning bells off in my mind that I've violated SRP three ways to Sunday.
This space for rent
|
|
|
|
|
|
Sander Rossel wrote: I really hate regions! 
They obfuscate the code, you only get to see parts of it, but I want it all!
If your code is really so properly written you shouldn't need regions.
I fundamentally disagree, Sander.
First of all, regions do not hide anything -- nobody holds a gun to your head and forces you to collapse them. Instead, they only allow you the option of not having to look at it every time you scroll up or down. Working in SQL all day long, I consider anything which makes navigating between key sections code faster or simpler to be A Really Good Thing.
Second, regions are a purely for organizing your code, and outside of a Microsoft demonstration there is no class too small to benefit from a little functional structure (e.g., these functions are for the customer UI, these are for the auditors, and those are for the order-fulfillment folks). If a single-page essay can be more readable by being divided into 3 regions (introduction, body, and conclusion), then what makes you think that a 6- or 7-function class couldn't?
Lastly, I question whether code is really any better when you take a 12-step chunk of linear (a.k.a. "spaghetti") code and refactor it into a 3-step process with each step having 4 layers of abstraction in the form of calls to other functions. I would say that there are many occasions where spaghetti code is more readable to both the human and the compiler.
|
|
|
|
|
|
William Clardy wrote: Lastly, I question whether code is really any better when you take a 12-step chunk of linear (a.k.a. "spaghetti") code and refactor it into a 3-step process with each step having 4 layers of abstraction in the form of calls to other functions. I would say that there are many occasions where spaghetti code is more readable to both the human and the compiler.
If it's code that works on only one layer of abstraction that's a bit longer, maybe like a stupid init routine for some hardware device in an embedded project, okay.
If that routine jumps between different levels, breaking it down into small functions will make it more understandable, because that untangles complexity which would otherwise have to go into your head all at once / you'll have to orient yourself in that complexity first. Whereas breaking it down into smaller chunks, you're basically outlining a graph of how things work.
|
|
|
|
|
I am with you on the using of Regions. I do not know why more programmers/developers don't use them.
A giraffe is a horse designed by a committee....
|
|
|
|
|
I can see using regions to collapse groups of related functions. Regions within functions mean that region should probably be a separate function.
Ed Aymami wrote: don't use them
Because it makes code hard to read.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I have to disagree. It makes code easier to read, particularly in the case where someone else wrote the code and you are stuck working on it. For one thing it allows you to focus on just the code you want to see, with out having to sift through, and/or be distracted by hundreds of lines unrelated to the problem you are currently working on.
It is productivity 101... If you are asked to pull the 3 of clubs out of a deck of cards that have been shuffled thoroughly, it will take you much longer to find it and pull it out than from a new deck in which all of the cards are in order by suit and denomination.
It is the same reason databases have indexes.
I will take code organized in this manner over code that is not all day every day.
Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about.
I have no idea how you got "Regions within functions mean that region should probably be a separate function" out of my original reply.
Duty calls.... I wish I was deaf sometimes.
|
|
|
|
|
Ed Aymami wrote: Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about.
Then we're not in disagreement.
Ed Aymami wrote: I have no idea how you got "Regions within functions
Because you didn't specify, but made a general statement about regions.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
This is key - very few will complain about you fixing things on your own. There is no need to complain - just take the initiative to make it better. Complaining is not constructive.
|
|
|
|
|
You've got to work on how you complain.
Taking the direct route ("This is cr@p!" or a paraphrase thereof) might seem the logical route, because it's the truth, but it's not the way to put the point across.
You're working with people, not machines, so you have to take feelings into account, just as you'd like others to take your feelings into account.
As you said, you (and you are not alone) have written shall we say "less than optimal" code, in the past, so before pointing out errors/problems, think about how you would like people to point out the errors/problems in your own code.
Then think of someone you work with whom you don't particularly like, and imagine how you would react to their "negative analysis" of your errors.
Take that into account when you want to tell someone that something is "less than optimal" -- e.g. phrase it "Hey, this was a good start, and I think we could build on it!", rather than "This needs to be rewritten!"
If you've already developed the rep of being a moaner, you should work very hard on getting things done without making that rep worse. Treating people as you would like to be treated yourself costs nothing more than a little thought.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: You're working with people, not machines, so you have to take feelings into account
Wow, that was deep
If it's not broken, fix it until it is
|
|
|
|
|
I get that way when I run out of beer.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
