What are the worst programming habits?

[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.)

[loctrice]

I'm all for comments when necessary. I know that is a wide range, but my pet peeve here touches on that range. I think comments can be useful, like if you need to remark on a pitfall about why the code is done that way. Or if you need specific thoughts to consider if you refactor. Stuff like that. However, when I encounter people who think code should be commented I run into two things that hit my peeve list: 1) comment everything, even if the comment is stupid 2) Don't worry about doing stupid things, because you can comment them. Use the comment instead of good architecture.

Elephant elephant elephant, sunshine sunshine sunshine

[Spoon Of Doom]

I've encountered a similar, but annoying variant of this. There were a whole bunch of functions in my old employer's code base which did nothing but call an almost identically named function, such as:

someFunc(int a, string b)
{
return some_Func(a, b);
}

In some cases, this went on for a step or two further, with some_Func calling some__Func (I HATE double underscores in code), which then again finally called the 'real' function someOtherFunc. I suppose it was the result of a messed up attempt at refactoring. It was hugely annoying when debugging.

[Andres Cassagnes]

I was working with a horrible C framework wich contains most of the worst programming habits. Very large functions (for about 4000 lines), no coments or coments like /*##@@&& and do something*/ (I swear its real) in a 1000 lines function and things like that. It was like the "1000 dont's about programming"

C, C++, Java, Verilog, VHDL, PHP, and still can´t speak english

[Pete OHanlon]

Charl wrote:

2. Refusing to commit code until it is "perfect"

There's another side to this. Excessive check ins. You don't need to check in every single change every time you make the change - wait until you have a logical break and then check it in. I've seen people check in every 5 minutes, just checking in things like colour or border thickness changes. It wouldn't be so bad if the next checkin wasn't for the next colour.

[J C Morris]

>back when I did do it, the cost of maintaining code far exceeded the >cost of developing it, and I considered a lack of meaningful comments >grounds for termination. I still do. +1 A friend of mine teaches programming for high-school students - and docks a student's grade if the programs aren't reasonably commented. Back in the early 1960s while in college I made some changes to a copy of Spacewar, and still have the source listings...but I have no idea today what those changes were. I hadn't learned about commenting (and in general neither had the other programmers who worked on the code). Now, as the senior engineer in my department at my POE I use those uncommented listings as examples of poor programming practice. (There are few things so horribly bad that they can't be used as a bad example.)

[Dave Kreskowiak]

I like to be explicit in my code. There is no doubt in my intent. I just find it a bit strange that "private" is the only exception to access modifiers where you have to be explicit about everything but only because it's default. I'm just saying that the access modifier shouldn't have a default forcing you to be explicit in your intent and (granted hopefully) think about what you're doing. I am happy to say, as the other replier pointed out, that I'm not one of those that needs to be "saved from himself" because VB made everything Public by default and that's what generates tons and tons of bad "public everything" code. I don't believe that the problem is with VB. I believe the problem is with the education and the lax standards of what should be taught in school. I've has more than few degreed grads that couldn't tell me the difference between public and private. I've also heard most of those same grads say they've never written an API, to which I call BULLSHIT since every application contains it's own API, usually for the sole consumer being the application itself. I think the entire "private as default" or whatever modifier is default is a Band-Aid on a bigger problem. EDIT: And just for the record, I'm going to admit to being a hypocrite. I also rely on private being the default in my own code but, just because I do it, that in no way means I think it's a good idea.

A guide to posting questions on CodeProject

How to debug small programs
Dave Kreskowiak

[Dan Neely]

Better auto complete systems don't need this. as a crutch to figure out what they should be offering as suggestions. It may have been useful a decade ago but belongs on the rubbish heap today.

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt

[Dan Neely]

To CYA in the future wrap that in a debug only block and let the app die more messily otherwise.

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt