|
Marc Clifton wrote:
Biggest Rube Goldberg POS I've come across in a while.
No offense but that gave me a good laugh. To each their own I guess. I like it though, mind you it does have its drawbacks. git merge is very picky for example. I never liked Subversion with its bandwidth intensive commits. I'm in the Kansas City Area so eventually I will have Google Fiber then it won't matter. I've never really used anything else and I haven't needed to. I can only fit so much stuff in my brain at a time. Whoops there went Java.
|
|
|
|
|
Deus ex Machina wrote: No offense but that gave me a good laugh. To each their own I guess.
 None taken - while I have strong opinions about Git, I know I'm the outlier, and so I approach my opinions with humor!
Marc
|
|
|
|
|
For me was a matter of start using it properly.
Before that I didn't even understand why people were so devoted to it.
And the raw you handle it, the better it becomes.
I used to be a TFS user and an SVN lover.
Now for me, TFS is gone and SVN is legacy.
But just to make it clear, is MHO.
Cheers,
Alex
|
|
|
|
|
Step 1: comment
Step 2: run for ages to make sure nothing broken by this
Step 3: delete
|
|
|
|
|
It's not so much so that I'm sure nothing is broken (I do testing to verify that); but more so that when I look at the code in a month's time I have a visual reminder that things in this bit no longer work the way they used to. I don't have any written specs from my main client, it's mainly coded "on the hoof"  and sometimes the client will ask about functionality. If I have to refer to the code and see old code commented out (with a date, of course!) I can say "until such-and-such a time it did that, now it does this". I could get that detail from source control but it's much faster if it's right there in the code, rather than having to check back in multiple old versions in TSVN. When the change is fully internalised (into my brain) and the client has got used to the new behaviour too, then I'll delete it. Of course the original, and commented, versions will still be in TSVN should I ever need to refer to it or check the date of the change.
|
|
|
|
|
Have to agree. That is way I do it.
|
|
|
|
|
Agreed.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Agreed. I routinely comment out a block of code, rebuild and retest, and then remove it later after the new block is proven reliable.
It generally depends on the complexity of the code being replaced. The more complex the logic, the more likely I am to keep the commented-out stuff around. That way I can easily compare the new and old code in place. I know you can do this with source control, but for smaller code snippets of a few dozen lines, using source control is cumbersome.
Software Zen: delete this;
|
|
|
|
|
Agreed on this.
Sometimes there's no better place to put a reminder than within the code as to why something was disabled.
No single raindrop believes it is to blame for the flood.
-irresponsibility@Despair.com
|
|
|
|
|
Agreed.
Works for moi.
// 20121224_165242;bkc ~ DEPRECATED: it was written to do such and such and
// replaced with NewFangledFunction().
I do put a datetime stamp and reason for obsoleting the code. Then, the next time I come upon it, if it's more than 6 months, 3 days, 14 hours and 23 minutes old (6 months is too open-ended) and I've heard no complaints, bye-bye archaic commented code.
|
|
|
|
|
Me too.
Although step two is also covers "the daft buggers who request things change their mind more often than their underwear and some part of this is just as likely to come back as not" and "I'm not the only one working on this so at least one committal with a comment explains in the code to someone else (or me) why something has been removed".
“I believe that there is an equality to all humanity. We all suck.” Bill Hicks
|
|
|
|
|
The old code exists in source control so go ahead and delete it. This is true if your kind of source control is to make a folder level backup of your project and putting it somewhere else in case the hoarding imp inside of you wants to go back later on.
|
|
|
|
|
|
This poll is a very extreme example of a poll with missing possible answers. Now I usually delete and in very occasional cases comment. However, I simply know that many people just leave the code in and simply "know" it does not get executed. Some only comment the condition and state, that it never gets executed.
The result is, that the clumsy people are not even left a chance to be honest, even if most of them maybe would not be honest, if they had the chance to be.
All in all, another poll that went down the drain. What a pity.
modified 25-Jun-13 19:34pm.
|
|
|
|
|
Agree. There are times when the user wants features removed, but I know they someday they're bound to want them back. I comment out that code and make it "inactive". To re-add it later, if it were deleted, would be significantly more difficult than re-integrating commented out code. It may be years that the code stays inactive, but when the day comes, I'll be ready...
|
|
|
|
|
I think the poll is just fine. 
In fact, I merely commented out the poll's web page in my browser history, because you never know when such a poll might be useful in the future... 
|
|
|
|
|
Yes it could have done with a 'I swing both ways' option... but then there's no real point to the poll if you have so many options that you don't really get anything definitive out of it 
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
CP article: SmartPager - a Flickr-style pager control with go-to-page popup layer.
|
|
|
|
|
I could certainly add many, many more answer options to a poll and asymptotically approach a set of answers the cover everything, or I can post a poll that gets a bit of discussion going. I know which one is more interesting.
Feel free to suggest a poll yourself[^].
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Alright, so you think I am suggesting, that giving more answer options is always better?
Choosing the right set of answers is not trivial and a key ingredient to getting informative results. Discussions tend to get off topic or just difficult to follow when most options are missing, because most posts are just about their own two cents and not react on the input other people give. Giving too many options obviously is also not productive, but having only two options for a question like this kills the result and the discussion in my opinion.
A discussion, enumerating what has been missing from the set of answers is not too interesting in my opinion, but I hope you find that interesting.
|
|
|
|
|
Wolfgang_Baron wrote: Alright, so you think I am suggesting, that giving more answer options is always better?
No, I was making an inside joke that no matter what answers I put in a poll there will always be someone, somewhere, who comaplains that I've missed an option.
So OK: What choices would you like to see to have a fully rounded poll that encourages debate without reducing the need for interesting discussion?
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
You have the option to not vote and add your comment on the topic in a more detailed way.
Please abstract from the actual poll result - this does not really matter - it's more about triggereing a discussion on the topic.
Cheers
Andi
|
|
|
|
|
If you know the logic just add a line why the code has been removed with version if you want to maintain it too.
It's really far better dumping out the unnecessary code and keep your code neat and clean.
Sometimes it may happen that you need the removed code, if this is the possibility why you kept it commented; then you should also agree with the possibility that you could come up with far better logic next time for the same thing. But only because you've commented it you will never even think of that.
|
|
|
|
|
While working I comment out but come commit, the old code is deleted. Dead as French Attack.
Reality is an illusion caused by a lack of alcohol
|
|
|
|
|
Nagy Vilmos wrote: Dead as French Attack
Like the battle of the Chesapeake?
|
|
|
|
|
For me, it depends on the situation, I have created utility libraries for debugging live code. And I will comment out the one or two lines of code that access the utilities. However the lines are commented as to their function and how they are used.
When we develop a new product we generally use one of a set of communication protocols but as new parameters are introduced it is useful to see how the data stream is being parsed. It can be a real time saver.
Code that serves no purpose because of code reduction or improved processes, need to go away.
It was broke, so I fixed it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
