Coding - so what's a crime and whats a misdemeanor?
-
Having multiple return statements in a single function. :thumbsdown:
There are only 10 types of people in the world, those who understand binary and those who don't.
Having a single return is a guideline that I mostly follow. First I aim for short functions so it tends not to be a problem. Secondly returning initially after a condition check and then again at the end is common and fine. Sometimes it actually reads better that way. But long spaghetti methods with returns all over the place is definitely a no-no. Again, I once had to maintain some code in which the single return rule was followed slavishly. The code was mostly pretty impressive but in one case there was a bug caused precisely by slavishly adhering to this rule.
Kevin
-
Well according to the BBC, the recent Talk Talk hack was a simple SQL injection. This from an 'internet' company. Talk Talk is criminal, sounds right to me. Committing code that doesn't compile can just be a case of not including a file, so I'd say that was a misdemeanor. TFS will kindly do this for you at its will. Personally I'd say excessive use of design patterns turning the simple into the multifaceted complex is a crime. Any type that has the word 'helper' in its title- Crime. var - Crime Indentation with spaces - Crime More than 1 type per file - Crime Inconsistent naming - Crime
Regards, Rob Philpott.
-
RyanDev wrote:
Actually, there have been times when business requirements went back to what they were before and so uncommenting the code was quite simple. I don't leave commented code in forever though. After a certain amount of time passes, it can go.
I generally like to submit code in as clean a state as possible. My rule of thumb is that if I have committed commented out code at least once then subsequently I will remove it because I know I can get back to it. There are other cases where I might leave it in longer, e.g., if it seems likely that I may need it after some other piece of functionality is available. In that case, I leave a TODO comment explaining why. Should I subsequently learn that it's no longer needed I purge it.
Kevin
-
Having a single return is a guideline that I mostly follow. First I aim for short functions so it tends not to be a problem. Secondly returning initially after a condition check and then again at the end is common and fine. Sometimes it actually reads better that way. But long spaghetti methods with returns all over the place is definitely a no-no. Again, I once had to maintain some code in which the single return rule was followed slavishly. The code was mostly pretty impressive but in one case there was a bug caused precisely by slavishly adhering to this rule.
Kevin
-
Kevin McFarlane wrote:
hen subsequently I will remove it
Which means you cannot search for that code anymore.
There are only 10 types of people in the world, those who understand binary and those who don't.
It will be in the source code history.
Kevin
-
It will be in the source code history.
Kevin
Can you search through source code history? In Visual Studio, I can choose: this document, current project, and entire solution. I haven't seen anything that allows me to search through source control history.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Me too. I've used that method as loop control where the loop needed to go in sequence (0,1, ...) but it may be missing values. Another was for a HTML form that sends an arbitrary number of arguments - which I sequenced the naming convention but didn't have in an array. In the latter case, the exception was the only way to find the end. But these were always deliberate.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Can you search through source code history? In Visual Studio, I can choose: this document, current project, and entire solution. I haven't seen anything that allows me to search through source control history.
There are only 10 types of people in the world, those who understand binary and those who don't.
RyanDev wrote:
Can you search through source code history?
No, you can't but I don't find this too much of a hindrance to look back at my own commits of a file. The way I see it is if I comment out code and I've not left a TODO then it's quite likely that I really won't need this again so I remove it. Possibly it might stay for a couple of commits. But certainly as a consumer of other developers' code I find it distracting when it contains too many blocks of commented out code as you have a tendency to look at what's been commented out and it can break the flow of the code. If there is some really big stuff that is in progress that I really shouldn't commit yet then I would shelve (TFS) or stash (Git) it.
Kevin
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
GOTO yourRoom. ;P
Will Rogers never met me.
-
I'm just waiting for the first person to put "uses JavaScript" or "uses VB".
Whatever happened to that whole dissing VB thing? We didn't all inadvertently grow up, did we? :sigh:
cheers Chris Maunder
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Not freeing your pointers.
cheers Chris Maunder
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I can't believe you missed the "u" in "Misdemeanours". From what I know, Brits love "their" grammar. :laugh: My additions: Misdemeanours: n) Unnecessary async wrappers for synchronous methods n+1) Abusing
var(for C#) n+2) Under-usage ofsealed(for C#) Crimes: n) Spawning unnecessary threads n+1) Usingdynamicfor "predictable" types (for C#) n+2) Making everything "public" with no thoughts whatsoeverI ain't got no signature.
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I can think of lots, but most has been covered. Here's two crimes that make me cringe: - Bad comments (which is most), like commenting the obvious, wrong comments, comments with bad spelling and/or grammar, etc. - Christmas tree coding. if (...) { if (...) { if { ... } else if { ... } } else if { ... } } } Something like that (add a few layers, format it nicely and it'll start to look like a Christmas tree). - Just usage of a lot of if's in general.
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Depends on how you do it. I sometimes comment code with an
#ifdef old_code
#endifwhen completely replacing a function's implementation. This way, in the (near) future, if there are some issues with the function, I can see what I (or someone else) did in the original implementation. (note: in the long term, I do remove that code, but in short-to-medium, I leave it there) Best, John
-- LogWizard - Log Viewing can be a joy!
-
Eddy Vluggen wrote:
I heard that often :rolleyes:
What about when you are in the middle of a long process of sql things and then you call one SP that sets a value but is not critical to anything else. If it fails, it's OK because a separate process later on will fix it anyway. What do you do then with the exception?
There are only 10 types of people in the world, those who understand binary and those who don't.
Then it sounds like the process is organized poorly. If a separate process will "fix it anyway", then why does the original stored procedure need to be done at all? For that matter, if you've got processes that fix problems in earlier steps, then you've got a system built out of Band-Aid™s.
Software Zen:
delete this; -
Well according to the BBC, the recent Talk Talk hack was a simple SQL injection. This from an 'internet' company. Talk Talk is criminal, sounds right to me. Committing code that doesn't compile can just be a case of not including a file, so I'd say that was a misdemeanor. TFS will kindly do this for you at its will. Personally I'd say excessive use of design patterns turning the simple into the multifaceted complex is a crime. Any type that has the word 'helper' in its title- Crime. var - Crime Indentation with spaces - Crime More than 1 type per file - Crime Inconsistent naming - Crime
Regards, Rob Philpott.
Rob Philpott wrote:
var - Crime
why would that be? When using Linq, you often use var.
Rob Philpott wrote:
Indentation with spaces - Crime
Where I work, we indent using spaces :) Should we be put to death? :D Best, John
-- LogWizard - Log Viewing can be a joy!
-
I can think of lots, but most has been covered. Here's two crimes that make me cringe: - Bad comments (which is most), like commenting the obvious, wrong comments, comments with bad spelling and/or grammar, etc. - Christmas tree coding. if (...) { if (...) { if { ... } else if { ... } } else if { ... } } } Something like that (add a few layers, format it nicely and it'll start to look like a Christmas tree). - Just usage of a lot of if's in general.
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I often get accused of commenting the obvious but I was taught to, and still do for complex algorithms/methods write what I want to do in terms of words as a comment (my intended function). Then I write the code underneath. The comments were there before the code, so it'd take me more time to delete them. Sorry - if you find it hard to just scroll past that stuff...
-
I often get accused of commenting the obvious but I was taught to, and still do for complex algorithms/methods write what I want to do in terms of words as a comment (my intended function). Then I write the code underneath. The comments were there before the code, so it'd take me more time to delete them. Sorry - if you find it hard to just scroll past that stuff...
What people forget is that each comment is a line of code that has to be as carefully written as everything else and that if the code changes so should the comments. In the end, if there's lots of bad comments, people learn to ignore comments and miss the actual good comments! I've actually written a tip about it, Write comments that matter[^], because I see so many comments that add absolutely nothing to the code. I haven't seen your code, so I don't know if you do any of the stuff I describe in the tip, but if you do I ask you, for the sake of programmers everywhere, please reconsider this bad habit of yours! :laugh:
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Unsorted pick lists and dropdowns. This kind of thing is easy enough for even a blank slate intern to get right.
Do what thou wilt shall be the whole of the Law. - Liber AL vel Legis 1:40, Aleister Crowley
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
incorrect indentation combined with single statement control flow (no braces) Java/C/C#/C++
if (condition)
// 10 line lengthy explanation
//originalSingleStatementForIf;
futureStatementThatNeedsToExecuteInAddtionTo_originalSingleStatementForIf;FIX: Always use braces!
if (condition) {
// 10 line lengthy explanation
//originalSingleStatementForIf;
futureStatementThatNeedsToExecuteInAddtionTo_originalSingleStatementForIf;
}
