|
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!
|
|
|
|
|
Mark_Wallace wrote: so you have to take feelings into account,
 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
You make great points. And while you what you said should be obvious, I suppose sometimes a person has to hear it spelled out for them like that. I suppose this would've been easier for me if the person(s) in particular already didn't insult me, but whatever the case you still make great points.
Jeremy Falcon
|
|
|
|
|
OK, so you've got "enemies" -- but they're not really enemies, they're just people doing their jobs who don't want headaches, like the rest of us, so make an effort not to hate them.
What you have to do (or maybe you think they have to do it, but at least someone has to do it, so why not you?) is take away the "enemy" thing. They're your colleagues, after all, and want the best for the company as much as you do (one would hope).
Try talking to them honestly, in private -- not the "Hey, your work is cr@p!" honestly, but the "OK, I've been a bit brusque, but we're all under pressure and maybe I went too far, so I'm sorry" honestly, and work outward from there.
Someone has to light the peace pipe, and you might be pleasantly surprised at the results -- co-operation works a Hell of a lot better than combat, so make an effort to be on the same side as the people you're (stuck) working with.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Well, the good news is, I'm about to switch projects, so the person in particular I've been working with in the past months will no longer be a concern (I hope) in about a week. That being said, you are right about someone being the bigger person, but I don't think that means apologizing since I've never once told them directly their code was crap. But he (the main person responsible) has insulted me to my face more than once.
That being said, your points are great. I'll keep them in mind for the next project for sure.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I'm about to switch projects
That is good news, because things sounded pretty bad (been there, done hated that).
It's easier (and a lot less work!) to start fresh than to dig your way out of a hole, so all the best and good luck!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Thanks man, and thanks again for the advice.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: But he (the main person responsible) has insulted me to my face more than once.
Sounds to me like your manager has told him that you were complaining about his code and this is his way of saying "Fork you".
It's not enough to complain that something is wrong. You have to be prepared to show them why something is wrong - but, before you do that, why not take them to one side and say something like:
"Hey, I'm just looking at this piece of code here and I was wondering why you implemented it this way. I know I must be missing something because I'm sure you will have considered doing x first, and I don't want to change something elsewhere that's going to break this, so I was hoping you could walk me through this and any touch-points that could impact it."
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: Sounds to me like your manager has told him that you were complaining about his code and this is his way of saying "Fork you".
That may be the case, but I do know that this guy in particular doesn't really get along with any dev. So, I think I was just the next in line to deal with him. Yay!
Jeremy Falcon
|
|
|
|
|
Yes. All that worked well for me. Better to jump overboard and watch them going full speed into the iceberg. Be diplomatic or fight it out, it does not matter. The only difference will be what's left of you when you finally get out.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Hating seems easy and right when you're doing it, but it makes your life so much harder, and you're usually in the wrong to do so.
We all work with people who are less talented than ourselves (and, if we're lucky, we also realise it when we work with people who are more talented).
Do you give the receptionist sh1t? Or the cleaning lady?
If you don't, then that implies that you value them more highly than a developer who is marginally less talented than you.
That's a pretty sucky attitude, no? But it makes you willing to make receptionists/cleaning ladies feel happy in their work, but your actual peers (even if only slightly less talented/knowledgeable than you) have to suffer your vengeful ire.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Simply because those poor dears do exactly what you accuse me of doing. They pat themselves on the back for der ingenious ideas that nobody else came up with without ever asking themselves why that could be. The fall flat on their noses each and every time and can be grateful that some customers don't stand in front of their door with torches and pitchforks. One of them is a real star among the car manufacturers and I will never buy one of their cars if it has been produced with that particular software I had the geat fun to work on. Pushing the blame for the current desaster onto the guy who says 'I told you so' is convenient and eases their pain. Being blamed for their clever ideas then banned from all 'important' activities actually makes me feel less ashamed to have worked there.
The cleaning lady at least never claimed it's somehow my fault that there still was dirt lying around and the receptonist was occasionally moved to tears by the way she was treated.
There is more and others have had less patience and left for the same reasons. If you ask me, they have a very weak grip on reality by now. You want to know their latest grand plan? Now that the n*ggers on the field have deserted them, it can't be that the guys left over are responsible for any of the still abundant errors or downright embarrasments. It's the fault of the testers who did not find everything. And that's why I valued the receptionist, the cleaning lady, the testers and all who fled from this place more than those who crated the whole mess.
If anything at all, I was an idiot for putting up with this as long as I did. In other places I finished projects all by myself and had customers who praised the results. The poor dears you are protecting can't claim very much in that direction, but that does not keep them from anything.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
We've all had to work with @rseholes, there's no getting away from that, but most of them can be handled very easily if you just sit down and think of how to handle the situation (and them), rather than lose your temper and quietly simmer.
None of us here is stupid; we just have to use our major assets to find intelligent solutions to problems -- use your head to think, not for butting.
Think of whom you need to talk to, and what you need to say -- but remember my dear ol' granny's tenet: If you can't say something nice, don't say anything.
If you get angry and butt heads with @rseholes, you're as much a part of the problem as they are -- but you make it a problem that someone else will resolve, without consulting you.
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
