Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small things like formatting/etc. There are obviously things like variable names that it wouldnt be able to solve but at least nobody would be complaining about where Joe put his curly bracket. I guess you can do something similar with an SVN hook but its hard to get a seamless process.
What was the strangest coding standard rule that you were forced to follow?
11–20 of 83 posts
Re: What was the strangest coding standard rule that you were forced to follow?
#12None were strange. I agreed with all the coding standards I have been forced to follow. The key to not be annoyed by them is to not work at places enforcing stupid standards :)
Re: What was the strangest coding standard rule that you were forced to follow?
#13I've been asked that I avoid using classes, because my boss didn't understand OOP (LAMP stack).
Re: What was the strangest coding standard rule that you were forced to follow?
#14I'm not sure what's up with all the hate for reverse hungarian notation, but I personally think it is helpful when writing C/C++.
I think it is crazy. Especially today, when IDEs can show you the declaration of a variable or method while hovering over it, there is no need to encode the type of a variable into the name. Variable names need to be sensible to humans, the compiler doesn't do checking on them anyway: it's all too common for the type prefixes to become misleading when a program has been refactored and they don't match up anymore.
It is crazy if you misuse Hungarian Notation like 99% of the people out there
For the 1000th time
"there is no need to encode the type of a variable into the name"
It's not the data type (int, char, etc), it's the nature of the thing being counted!
Number of apples, height, distance, etc
But of course when saying "type" most people would think it's the data type when it's not
Re: What was the strangest coding standard rule that you were forced to follow?
#15Earlier quoted context omitted.
I think it is crazy. Especially today, when IDEs can show you the declaration of a variable or method while hovering over it, there is no need to encode the type of a variable into the name. Variable names need to be sensible to humans, the compiler doesn't do checking on them anyway: it's all too common for the type prefixes to become misleading when a program has been refactored and they don't match up anymore.
It is crazy if you misuse Hungarian Notation like 99% of the people out there For the 1000th time "there is no need to encode the type of a variable into the name" It's not the data type (int, char, etc), it's the nature of the thing being counted! Number of apples, height, distance, etc But of course when saying "type" most people would think it's the data type when it's not
I'm not sure what you're referring to, but in all instances of Hungarian notation I've seen (especially in Windows programs) it was the data type (pointer to char, 8 bit int, 32 bit int etc) encoded and not "the nature of the thing".
I agree that adding the "nature of the thing being counted" makes sense, but then you don't have to call it Hungarian notation anymore, "number_of_apples" is just a sensible variable name...
Re: What was the strangest coding standard rule that you were forced to follow?
#16On a vaguely related note, there was a project kicking around a month or so ago to store editor-neutral code formatting specs in the project root. Can anyone remember what it was? My google-fu is failing.
Re: What was the strangest coding standard rule that you were forced to follow?
#17 > To NEVER remove any code when making changes. We were told
> to comment all changes.
Re: What was the strangest coding standard rule that you were forced to follow?
#18Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small…
I know a solution: Agree on the broad points of formatting - ie. tabs/spaces, where the braces generally go. Make engaging in formatting battles a firing offense, but listen to anyone who can make substantial arguments in favour of a practise.
Automatic reformatting is evil - sometimes codes is more readable if formatted in a particular way. Readability and maintainability always trumps adhering to rules.
Re: What was the strangest coding standard rule that you were forced to follow?
#19Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small…
so I would have something on L249 and you would have it on L321? nonsense.
Re: What was the strangest coding standard rule that you were forced to follow?
#20Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small…
What I've always found an intriguing idea is to store the abstract semantic graph of the program instead of (just) the text of the program in the revision control system. The source code could then be formatted / visualized in any way for the programmer while manipulating it. Kind of like a TeX, or CSS, but for source code. And I suppose it could also help with making sensible diffs, no longer need to be annoyed by addition of spaces / indentation / number of columns / etc.