My Daily OHN
-
My Daily Oh Hell No: I just had a developer complain (yell) to me because I always run code cleanup when I see incorrectly formatted code (we use resharper with predefined settings to auto-magically format the code). This of course can make doing SVN commits a pain if it results in a manual merge. Do I give in and only do this "once a week" as requested? :sigh:
Todd Smith
Hell No. In fact I'd be pretty draconian about requiring your coding standards be meet before a single thing gets pushed back into the repo.
And above all things, never think that you're not good enough yourself. A man should never think that. My belief is that in life people will take you at your own reckoning. --Isaac Asimov Avoid the crowd. Do your own thinking independently. Be the chess player, not the chess piece. --Ralph Charell
-
Complain is OK, yell is not. As much as I love reformatting and improving comments, they make some maintenance tasks a pain. Having to find the significant change between two versions when 90% of the diff is formatting makes me want to yell. (Take note: want to, not do). I don't see how "once a week" would improve that, though. I'd argue for: A standard format that is achieved automatically e.g. by resharper and is USED BY ALL BEFORE COMMITTING. (see there, only almost yelling) For old code... tricky: "leave as is unless it's really really bad", or "cleanup, but rarely". Or get a merge tool that can ignore whitespace UNLESS IT'S IN A STRING. (now I did yell. Bad tools make me do that :()
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.I concur. Automate it, and have it run on every commit. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Getting an article published on CodeProject now is hard and not sufficiently rewarded.
-
I concur. Automate it, and have it run on every commit. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Getting an article published on CodeProject now is hard and not sufficiently rewarded.
-
Likely the best solution, but might be cause office wars.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.There shouldn't be if you do it from the start. Setting it up halfway in the project's life time would cause some pain though. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Getting an article published on CodeProject now is hard and not sufficiently rewarded.
-
My Daily Oh Hell No: I just had a developer complain (yell) to me because I always run code cleanup when I see incorrectly formatted code (we use resharper with predefined settings to auto-magically format the code). This of course can make doing SVN commits a pain if it results in a manual merge. Do I give in and only do this "once a week" as requested? :sigh:
Todd Smith
My opinion: Don't change code, period, unless you have made a physical change. I have lost count how many times some errant dev has opened a file, not liked the formatting, hit a few hot-keys, and accidentally deleted something crucial, check in just formatting with full testing (because, hey, formatting can't possibly break anything) and leave for the day. Now, what I would do, if I were anal about code formatting (And I am not unless it is just plan inconsistent. I consider worrying about code formatting a sign of future project failure) I would not allow check-ins until after a code-review. You can then reject check-ins that do not meet your requirements rather than changing another developers code which causes issues.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
My Daily Oh Hell No: I just had a developer complain (yell) to me because I always run code cleanup when I see incorrectly formatted code (we use resharper with predefined settings to auto-magically format the code). This of course can make doing SVN commits a pain if it results in a manual merge. Do I give in and only do this "once a week" as requested? :sigh:
Todd Smith
If it were me deciding, I'd be tell you to do it either: 1) Never or b) Once per major rewrite. or c) Only on the method you are already changing or d) never. or e) Make sure you do it separate to any changes of substance or f) never.
-
My opinion: Don't change code, period, unless you have made a physical change. I have lost count how many times some errant dev has opened a file, not liked the formatting, hit a few hot-keys, and accidentally deleted something crucial, check in just formatting with full testing (because, hey, formatting can't possibly break anything) and leave for the day. Now, what I would do, if I were anal about code formatting (And I am not unless it is just plan inconsistent. I consider worrying about code formatting a sign of future project failure) I would not allow check-ins until after a code-review. You can then reject check-ins that do not meet your requirements rather than changing another developers code which causes issues.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
After my initial knee jerk, I think you're right. What would/could be nicer is to have the source code system auto format it on extraction or checkin. Good in some ways, bad in others.
-
There shouldn't be if you do it from the start. Setting it up halfway in the project's life time would cause some pain though. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Getting an article published on CodeProject now is hard and not sufficiently rewarded.
-
Luc Pattyn wrote:
There shouldn't be if you do it from the start.
Where's that time machine again? :rolleyes:
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.Actually, you don't need one. This would also work, assuming you have a formatting tool that is sufficiently bug-free:
check everything in
for each item in project {
for each existing version {
check out
run format fixer
check in (keeping metadata unchanged!)
}
}It may take a while... :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Getting an article published on CodeProject now is hard and not sufficiently rewarded.
-
Actually, you don't need one. This would also work, assuming you have a formatting tool that is sufficiently bug-free:
check everything in
for each item in project {
for each existing version {
check out
run format fixer
check in (keeping metadata unchanged!)
}
}It may take a while... :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Getting an article published on CodeProject now is hard and not sufficiently rewarded.
That would solve it - I don't know if that's possible in Version Control systems. One could rebuild a "reformatted" copy faking the commit date... Sounds almost like a time machine ;)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
My Daily Oh Hell No: I just had a developer complain (yell) to me because I always run code cleanup when I see incorrectly formatted code (we use resharper with predefined settings to auto-magically format the code). This of course can make doing SVN commits a pain if it results in a manual merge. Do I give in and only do this "once a week" as requested? :sigh:
Todd Smith
Todd Smith wrote:
auto-magically
I'd yell at you for saying that, so you can't win.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Todd Smith wrote:
Do I give in and only do this "once a week" as requested
Once a month sounds more appropriate. :) Merging is an awful task.
Me, I'm dishonest. And a dishonest man you can always trust to be dishonest.
Honestly. It's the honest ones you want to watch out for...