Comment Re:After 42 yrs programming I say... (Score 1) 430
Wow i meant this to be a reply to Decameron, and I didn't even realize it was him who replied to me. Sorry, man, didn't mean to refer to you in the third person.
Wow i meant this to be a reply to Decameron, and I didn't even realize it was him who replied to me. Sorry, man, didn't mean to refer to you in the third person.
I will happily meet you in the middle about their intended purpose, and I wouldn't have argued with Decameron if he had stated his opinion in your way. The problem was he didn't leave room for the possibility that they don't actually fulfill their intended purpose in his statement.
Then how about you standardize the IDE?
Who are you referring to?
I saw two arguments from the first guy, and I addressed both of them.
If you're referring to two different local variables of two different functions, then obviously that is the case, and the change in the styles shouldn't matter, as they are in fact two different variables.
Well I would actually say that changing variable names simply because they don't comply with the standard isn't only a productivity issue. It is bad practice and a productivity issue. I would want the diff to show the change for two reasons. 1. it isn't a trivial change to change a variable name like it is to change whitespace. This can introduce bugs. 2. the productivity issue.
I would also say that I would never, ever, ever use an IDE which would change the actual variable names and not just the whitespace. Bill sounds like he needs to attend anger management if a style change makes him angry.
You assume incorrectly. This is common sense.
Well my argument to man of mister e and first reply to Decameron are two different arguments.
My argument to man of mister e, was simply to imply that using features in your diff program can help you ignore meaningless differences in styles.
My argument to Decameron was in reply to his blanket statement that "the reason why coding styles exist is that they increase the readability of your code." This is an absolute statement about the nature of coding styles, which is factually incorrect, as I have demonstrated by personal experience as well as well known failures from the daily wtf.
I don't disagree that there needs to be at least some level of tracking (usually the kind inherent in most source control software). As stated in another reply, understanding the programmers original logic can greatly help things. I agree that it can also help you find the source of malicious code.
Brace position and spacing both are encompassed by the whitespace argument that I was referring to. Also I would say that if you have a programmer who chooses to change the variable names of their inherited code simply because it doesn't conform to the standard, then I would say you have more to worry about than coding style.
I'm not seeing the issue. If a dude is changing variable names, then I would want to know about it as that is less trivial than whitespace changes.
This seems like another productivity issue. If I have a guy focusing on changing variable names from myVar to my_var, then he's either going to be talked to and told to wisen up or canned as he's not doing anything productive.
And you're missing my point when I say that just because a particular style is standardized doesn't mean it produces self-documenting code. If the person in charge of setting the standard is an incompetent programmer to begin with, then his standard could introduce confusion. There are many examples of this happening on the daily wtf. And in fact, I have had managers that have tried to enforce standards which would turn my code from easily understandable to a mess of variable acronyms.
To a competent programmer, stardards are more of a guideline. Any good coder knows how to produce clear and maintainable code, and should be able to read similarly clear code even if the case of the variables are different or there is an endline after the curly braces. Bad coders need and cling to these rules, however, because without them they would literally have no idea what to do.
Sorry, it was your wording in your original statement which made me assume that you were talking about this horrible practice. I definitely agree that knowing who originally coded something in order to find out their logic is extremely important, especially for those little bugs, just have a horrible aversion of people on my teams pointing fingers at each other instead of actually doing their jobs.
His first point was clearly addressing the differences in whitespace. Any moron complaining about whitespace in code doesn't really belong in coding. Diffs can and should ignore whitespace (unless you're talking about languages that don't ignore it), so his point was moot. And I personally have enough experience to know exactly what he is talking about
Assigning blame to people because of bugs is in fact one of the most detestable things you can do in software development. Bugs will always exist, no matter what coding style you use. If your first priority is to name and shame and not fix the code and move onto the next issue, then your teammates are going to hate you.
The end of labor is to gain leisure.