|
Apart from commenting there are much worse bad habits. My favorites are:
1. Copy & Paste code; partly mdified.
2. Caching; this means holding the same information at different places. Entropy mandates that these differ after a while.
|
|
|
|
|
Some of the early computer systems were very restrictive regarding lines of code making insertion of comments difficult. I remember writing a debugging subprogram that carried the comentary for the main program. Somewhat self-explanatory, except I forgot to comment the trigger.. . Panic call from customer at 3AM wondering why printer is spewing 3700 pages of gibberish.
|
|
|
|
|
Being overly complex to prove how smart and bleeding edge you are, with the bad variable names and no comments.
At least when I did a variant of Duff's device, I laid the case statement over an if/else, I commented what was going on and why. I was young and 'smarter' than I am now.
Comments should give the why something is being done or changed.
git. I work on source files not directory structures. If I want to check in a single file but have messed around in a bunch of others that I'm not ready to check in yet, don't make me do something with them. (How I miss PVCS and file locking.)
|
|
|
|
|
MarkTJohnson wrote: I work on source files not directory structures.
 That's an issue I have with "modern" version control systems I've had to use (TFS and Subversion). But I think it stems from Visual Studio and other tools that also insist on working with directory structures rather than individual files. 
The tools we use shouldn't force everyone to use one particular technique.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I'm definitely guilty of 4, though I try to make comments about it
And here's an extra one two:
Using and IDE integrated Task List (ie VS) : overuse of TODOs - damn things pile up quickly.
Ignoring compiler warnings. They're sometimes useful, and ignoring the buildup of minor things can make you miss big things like architecture mismatches
|
|
|
|
|
Your + a few others mentioned and:
- Procrastinate
- using var everywhere
- Ctrl+C, Ctrl+V and not even bothering to change variable names to reflect their new meaning 
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Hard-Coding values that should be looked up....that never ends well. We have a guy here that continually thinks that's ok to do (why would it change?), and it's bitten us more than once.
|
|
|
|
|
Chris Maunder wrote: What's your list?
1. Building something because the developer wants it rather than because a customer wants it.
2. Assuming that because something is new that it better.
3. Assuming that because something is new is it without fault and requires no time learn to use well.
|
|
|
|
|
I think i'm guilty of the first one, although I usually only comment when it's not clear what the code does or it may have some unintended side effects.
|
|
|
|
|
Using too many if-statements where better suitable mechanism could be used instead.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
ctx - it is assumed that it should point to some context structure, it is(should; may) not variable in usual sense but rather - the function parameter so it may be "pure functional".
|
|
|
|
|
I have nothing to say against use of comments. They may not be necessary for some, but usually do no harm to anyone.
I believe programmers are free to choose any name for a variable so long as they communicate well to people you work with. Using "o" is fine. If it's a problem, change your font.
Bad formatting used to a bad practice, but nowadays, we have apps and services to make them neat.
|
|
|
|
|
Thanks for this week's survey - it's great!
/ravi
|
|
|
|
|
|
My Rep Points - which happens to be a Prime Number 
|
|
|
|
|
But that is not your Rep Points.
|
|
|
|
|
Then let's wait for 56773
|
|
|
|
|
You missed that one as well! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Yes, and I missed 56783 as well and hoping to see 56807
|
|
|
|
|
Eeee! Bad news... 
I could find a couple of questions or answers from you and down vote them? That would give you another chance?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
And you can wait for 1038017 as well.
|
|
|
|
|
Not worried - I'm waiting for 1,048,476.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: 1,048,476
Quite achievable, I guess.
|
|
|
|
|
Too bad it was gone the second you posted that 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Yes, I realized that, and that's why I'm ready with a list. I can enjoy as I hop through as many of them
56767
56773
56779
56783
56807
56809
56813
56821
56827
56843
56857
56873
56891
56893
56897
56909
56911
56921
56923
56929
56941
56951
56957
56963
56983
56989
56993
56999
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
