|
GOTO can be useful and there are moments where it is needed. Misusing it can result in spagetti code I know but...
I would like to see you coding in LAP (PLC) or assembly without JMP instructions...
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's why I added the second sentence.
|
|
|
|
|
mmmm... ok. I forgive you  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
There's an example in Code Complete (first edition at least) where they provide a code example using Goto. Apparently almost no-one was able to rewrite the code correctly without using Goto. 
Kevin
|
|
|
|
|
Jörgen Andersson wrote: D) Use GOTO.
so break and return are not to be used?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
They all become jumps in the end.
Breaks, returns and exits have a quite lower probability of becoming pasta.
|
|
|
|
|
Those are not gotos.
Aside: While simplifying some code this week I removed a switch (that was inside a while) ... and later realized that I hadn't removed a break that was left over. 
I really dislike that break operates on switch -- I hope DMR's harp gives him blisters.
|
|
|
|
|
True - back when I was at university in the late 80's we were taught 'structured programming' and anything that threw you out of an iteration was forbidden, until year two when we were told that there were circumstances where there was not other option.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: anything that threw you out of an iteration was forbidden
But break goes only to the end, not somewhere completely different, it's structured (still prefer to avoid it though).
|
|
|
|
|
I've used GOTO in driver development when it made sense. Generally speaking I don't use it but when it's needed there's nothing wrong with it.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
More to the point: I have not seen a GoTo in the wild since VB6 - and even then only for err handling (On Err Goto).
I would seriously doubt that GoTo is a real problem in any .Net shop.
|
|
|
|
|
D) Storing numbers and datetimes as string in database / counfounding a value with its string representation.
E) Not reading the documentation of the objets used in the application.
F) Not checking/validating user inputs.
G) Copy-pasting a code from anywhere on Internet and expecting it to work without having to think about the requirement ; asking someone else to solve the problem when copied code does not behave the exact desired way (without defining the correct behaviour whatsoever).
I never finish anyth
|
|
|
|
|
D.1) Storing "numbers" as integers just because they're called numbers.
(Telephone numbers, social security numbers, etc.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
So true
I never finish anyth
|
|
|
|
|
|
|
Committing commented-out code. I'm not sure whether it's a misdemeanor or crime though.
|
|
|
|
|
harold aptroot wrote: Committing commented-out code.
That's called good practice. 
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.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
One of the biggest dangers in software development is when code gets into the code base without first going through the human brain.
Un-commenting a block that looks like it shouldn't be commented out is a classic way that this occurs.
|
|
|
|
|
Duncan Edwards Jones wrote: Un-commenting a block that looks like it shouldn't be commented out is a classic way that this occurs.
Never heard of someone doing that. If you thought that was what I was suggesting, you misread.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
No - I'm suggesting it can happen if code is commented out and then the result checked into source control....
|
|
|
|
|
Any code that has implemented some sort of source control shouldn't have any commented code.
If your customer wanted to go back to previous functionality, you should review the source code history to retrieve it from there, it should even be wrapped up in a single check-in with all the dependencies that the functionality relies on.
You can comment code during development to test other avenues, in fact, I think can use whatever coding practice you like while developing but it shouldn't get committed into the code base.
Sorry if this comes across a bit sour, but I'm working at a place that used to use commented code as source control... They have source control now, but they haven't grasped the concept very well and the code is littered with obsolete, misleading and blatantly wrong comments  
So... crime.
|
|
|
|
|
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
it's often handy to leave commented-out code in place if it shows what was already tried but didn't work.
if you're using a third party library, for example, and the docs lead you to think that doing X,Y,Z should work, but after talking with the authors you learn that your situation is special so you really need to do W,X,Z. seeing the incorrect (and well-labeled as incorrect!) code can steer future developers away from making the same mistake.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
