What are the worst programming habits?

[Herbie Mountjoy]

Re-using code blocks in different applications without checking that the pre-existing comments are relevant in the latest incarnation. I keep finding examples of this in my archive. Stupid boy...

I may not last forever but the mess I leave behind certainly will.

[greldak]

Nish Sivakumar wrote:

Sometimes, it is though.

not really - the comments that are there are irrelevant but the ones that are needed are missing. The user is valid so why does it need updating?

[Member 9063556]

1. Leaving Edits in the code (Edits are messages that often pop up in developmental purposes for our in-house testing) 2) Bad tabbing. Don't blame me, really. I use a different tabbing structure due to the program we use doesn't automatically tab things well.

if (Broken) then fix.this else !fix.this end-if

[Rosenne]

Wrong or obsolete comments.

[Mel Padden]

I've seen the best and worst of stuff, but I've grown so used to it I just edit it out. There are modern tools to autoformat code in any case, I think the only things I would seriously have a problem with on that list are 4 and 5. Worst coding pet peeve? Code that isn't written defensively, with a mind to robustness, or that is not fully tested.

I too dabbled in pacifism once.

[SortaCore]

Some code I write includes the "sneaky minus".

someFunc(300, 250 * abc, -(500-otherVar * (3+abc), 592.3f);
// ^

I generally document that, unless the logic shouldn't ever need changing.

[SortaCore]

pfld_ is a pointer to a fixed long double and it ranks under other variables in testing. Hence, the underscore notation.

[SortaCore]

class uhoh
{
bool yay;
uhoh(bool yay)
{
this.yay = yay;
}
}

... is usually the only time I want to use "this". Unless there was another "uhoh" being involved in an uhoh function. Which is probably not good practice.

[Lost User]

I'm not into saving keystrokes; but it does convey the same information using less symbols. For your comparison:

// Delphi style;
procedure Test()
begin
end

// C#
void Test()
{
}

Would you like to imply that we use "{" and "}" merely to save keystrokes? You cannot deny that C# is a bit more readable than COBOL. Still, feel free to state the obvious if you feel like you have to :) It's a non-discussion. Try

11 + 2 = 13
Eleven plus two is thirteen

Would we prefer the first version, just to save keystrokes? And which of the two explains the fastest what is going on?

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

[Lost User]

PIEBALDconsult wrote:

the class is private? :confused: How does that work?

Create a new console-application. Look at the access modifier for "Program" and it's entrypoint. Both are private. Surprised? :)

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

[Lost User]

Can you explain the reason? :) There is no good argumentation. "This" is used for the nut-cases who don't want to prefix with an underscore, and it is one of the most abused keywords, littering code without adding ANY value whatsoever.

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

[Stefan_Lang]

Eddy Vluggen wrote:

Should I prefix each class with a complete namespace

Maybe not each, but I've found that some namespaces use way too simple names to be safe to use without! E. g. in C++ I never use using namespace std, since it clutters the global namespace with many symbols that are common enough that they may clash with just about every nontrivial application code.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Stefan_Lang]

One of the common errors of OO design is making everything public. Being private by default means that this won't happen by accident, or out of sloppyness. i rather have the compiler complain that I forgot an accessor than having other programmers modify my internal state because I forgot to explicitely make them private!

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Stefan_Lang]

harold aptroot wrote:

- Unreachable code. Often mistaken for "defensive programming". Code that provably can't run is provably useless.

Dunno about that one - I once inserted a check that I was 100% sure couldn't possibly fail, so I inserted a message saying this shouldn't be happening, and to please contact me. Thank god, it was a beta tester eventually seeing said message, not an actual user in production code - it turned out I was wrong on my 100% assumption... :-O

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Lost User]

I hope it wasn't provably unreachable, that would have bad implications for the fabric of reality.

[Peter Adam]

Then please show me the way parametrizing a table name, or field names in a query. Of course, you can keep hacking[^].

[Peter Adam]

But if you are only scanning the code you can focus on the green lines instead of running an in-memory compiler :)

[Stefan_Lang]

SortaCore wrote:

unless the logic shouldn't ever need changing

That's a rather roundabout way of saying 'always' ;P

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[SortaCore]

Yeah, when coordinates are no longer used in printing, the logic will need changing. :rolleyes:

[Fran Porretto]

Allow me to submit something a bit off-axis: a habit of thought.

In more than one place where I've worked, I've encountered persons so confident in their skills that they didn't bother to test "trivial changes." Such "trivial changes" caused major crashes in important products, more often than I (or they) would care to remember. Inasmuch as for many years it's been a large part of my responsibilities to train young software engineers, it's been the very first thing I've pounded on: there is no such thing as a change too small to test.

Some took the advice to heart, but not all -- and when the bills came due, the incredulity of the sinner at issue was often thick enough to slice: "But all I did was...!"

We're fallible, each and every one of us, from the dunces to the geniuses, and from the brand-new graduates to the fifty-year veterans. But an engineer's ego can be resistant to that homily...until he's experienced the consequences on his own hide.

My "favorite" case of excessive confidence involves a young turk -- let's call him Andy, as that was his name -- who was assigned a component in a large monolithic application intended to run on a VAX under VMS. Andy was excessively fond of assembly language, and was eager to write his piece in VAX assembler. I counseled him against it -- the rest of the application was written in C -- but couldn't dissuade him. To shorten the story a bit, some weeks later Andy presented me with his component, which I added to the build without comment. The resulting application ran for approximately twenty seconds before it crashed -- and it didn't just bring down the app; it crashed VMS with a "bug check" error.

The problem was, of course, in Andy's module. I pointed it out to him at once. The subsequent exchange ran roughly as follows:

FWP: Did you test it?
Andy: Well...
FWP: This instruction [I pointed it out] is out of sequence. You have to allocate and enable mapping registers before it will be valid.
Andy: Well...
FWP: I expected you to test this before you brought it to the link.
Andy: But it assembled without errors, so I figured it was right!

Words fail me, friends.

(This message is programming you in ways you cannot detect. Be afraid.)