|
CodeWraith wrote: I hope I sucessfully fooled you into coming over and expecting a beer.
I'm at your door, why won't you open!? 
CodeWraith wrote: you must see that your one and only style may be just as problematic or misleading for the next guy
Never in the current team because they all know and recognize the style.
And I hope the next guy (or girl) needs a few minutes to get used to it and then says, "alright this code seems tidy which makes it easier for me to read it and understand it".
CodeWraith wrote: when someone writes something upper-, lower, camel- or even briefcase?
When I see a variable in PascalCase I assume it's either a constant, a method or a property.
Likewise, when something is camelCased I assume it's a private variable, scoped to the current method or class.
When I see an underscore prefix I assume something's a field (and that the programmer is a little older).
I'm fine with a different styles, it's not my way or the highway, but this is something a lot of (.NET) programmers can relate to and sticking to that style will make things easier to read for many programmers after me.
Of course, when I'm doing JavaScript I never use PascalCase and use camelCase instead.
Again, I've seen PascalCase JavaScript and I'm fine with that, as long as it's consistent (although the first sight of PascalCase in JavaScript does trigger me a bit because it's unexpected).
In the end, however you write your code, I will be able to understand it and to change it, but your code style (or lack thereof) may be the difference between a "that wasn't so bad" and a "wtf was that idiot thinking!?" 
Style will never make up for lack of skills and if I had to pick between a skilled and sloppy developer or an unskilled and tidy developer, I'd go for the skilled one.
But why not skilled and tidy? 
|
|
|
|
|
Sander Rossel wrote: But why not skilled and tidy?
As long as you don't make a religion of it, including conducting code reviews like the inquisition and hobby advocates who constantly add new rules to the 'style guide', plus previous decisions of the inquisition and lists of exceptions to the rules.
I prefer not to degrade the entre team to code monkeys or better secretaries. Remote controlling everyone and dictating exactly what they have to write and where they have to put it is much too stressy. Then it's easier to just write it myself.
A more tolerant approach does not descend into anarchy. Your team will automatically find a style that everyone can live with, simply because they start to feel responsible when they are not constantly discouraged by some control freak. I learned that lesson very early, at a place where most people would not expect it.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Varied skill levels of team members make style enforcement an important tool to be sure you can assign the work to almost anyone on your team without too much hassle about "style-stink". You just have to get buy-in from the team because enforcing it without their buy-in only increases resentment. That, and making in-line comments for hard-to-follow code blocks can make a world of difference for the guys who have to come in after you to maintain the code. That's my story and I'm sticking to it.
|
|
|
|
|
Here's my response to style freaks:
Your style sucks, their style sucks, my style sucks too
so now that we all agree on style next item on the agenda is?...
Message Signature
(Click to edit ->)
modified 19-Nov-19 10:29am.
|
|
|
|
|
My response to you:
I don't care, pick the style you think that sucks the least and stick to it.
Preferably the style most developers use in that particular language.
The next item on the agenda is tabs or spaces?
|
|
|
|
|
I agree that a certain amount of style is very useful. But I've worked too long with someone in, where style came before technical knowledge. And for such a case I prefer "No Style" 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Style never makes up for lack of skill.
But why not have skill and style
|
|
|
|
|
Style should be only a matter of choice, point of view of the reader or writer. Saving the code should be style independent and be given by the grammar of the language. I have experienced "git" fundamentalists who have banned the use of high level XML editors (= even for web.config, etc.) because saving in a different style evokes file changes. So you must not use advanced XML tools, etc. In a word, you must be a stupid programmer. As long as IT focuses only on technology and business logic is a minor matter, we will still have to deal with 90 to 95 percent of the time with uselessness and not with useful programming. So we will come up with new languages and practices (like DevOps) and increase Babylon. After all, guessing what the program is doing (for all hell) is amazing fun, isn't it?
|
|
|
|
|
Super Lloyd wrote: Avoid excessive inheritance
Quote: A type is more than four levels deep in its inheritance hierarchy.
Wow. I have seen samples to teach about inheritance which already are 'excessive' by this definition.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Static code analysis gives you an indication where your code might not be optimal. It is not like they are carved in stone.
It's like going to a doctor; checking helps to prevent larger issues and doesn't cost much, but you are still allowed to ignore the warnings about your smoking-habits.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This particular doctor costs more than it's worth by mindlessly applying rules which are so restrictive that even code samples are already 'excessive'. What would you say about a doctor who at the same time lectures you about eating too much and doing too much physical work? An apple and some bird seeds may be enough for a supermodel, an athlete would not come very far if he tried that.
As we know, computers do not really shine when it comes to good judgement and intelligently combining separate results. That's also why I see the current AI hysteria with horror. I would sooner let a trained monkey drive my car than a computer. This thing here is not quite as dangerous. It just wastes my time with countless irrelevant warnings and drowning out the relatively few ones that might be relevant.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Turn the rule on to not waste an hour of your life with code analysis.
You either write good code or you don't. Empower yourself, not the machine.
|
|
|
|
|
The frustrating bit is.. I spotted a few useful tips... but there is like 400 messages for one assembly, of which maybe 5 messages are useful. But in the end I search and find these messages like once a year... I am never gonna scan them all successfully on every compile or even once every day...
And then.. it's working less and less well to turn them on and off.. (between each edition of visual studio) but that might be because I have the Community edition at home. Going to check pro edition at work tomorrow! Would be good to know if professional works better.
|
|
|
|
|
Super Lloyd wrote: I told it to ignore rule 2208
Do you like to run around in a bathrobe all day ("Execute order 66!") or do you prefer something more colorful ("Implement General Order 24!")?
Every nerd who knows what I am talking about may drop a comment
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I am gonna order 66 the godamn code analysis extensions! 
|
|
|
|
|
Not General Order 24, just to be sure?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
Order 66 is from Star Wars, General Order 24 from Star Trek. It may be unusual for the 'good guys', but in some situations you must show your muscles when someone does not want to listen to anything else. They would probably not have had to go all the way to the bitter end, but anything less would end any hope of avoiding it altogether. War is a messy business.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I like your comments about wanting the freedom to change styles over time. In general we are getting sick of 'Nannyware' that keeps telling us what to do or not to do.
|
|
|
|
|
Thanks man, glad the feeling is shared!
And indeed I have heard less complaint about consistent style those last few years...
|
|
|
|
|
|
I already read the books! 
|
|
|
|
|
So did I - then I watched Series one. Both telling the same story, both very good. But both doing it differently.
It is worth watching the TV series after reading the books - and I'd be damn sure it's worth doing the other way as well.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: "I'm free right now."
Ooh, is that you Mr. Humphries?
|
|
|
|
|
Making the missus watch all the prior episodes with me in anticipation.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
