Outdated coding practices [closed]

Question

As I do my coding I sometimes wonder if I'm doing things the best way or just the way it's always been done. Does what I'm doing make sense anymore?

For example, declaring all your variables at the top of the function. If I try to declare it twice or below where I start using it my IDE will bark at me at design time - so what's the big deal? It seems like it would make more sense to declare the variables right above the block where they'd be used.

Another one would be hungarian notation. I hate that all my variables related to a particular object are scattered throughout my intellisense.

With modern advancements in frameworks and IDE's, are there some coding practices that don't really apply anymore and others that may be just plain wrong now?

Answer 1

Don't declare variables above the block where they'll be used - declare them in the narrowest scope available, at the point of first use, assuming that's feasible in your language.

Hungarian notation will depend on the conventions for your language/platform. It also depends on which variety of Hungarian you're using - the sensible one (which I'm still not fond of) or the version which only restates the type information already available.

One thing to watch out for: when you take up a new language, make sure you take up the idioms for it at the same time, particularly the naming conventions. This will help your code fit in with the new language, rather than with your old (probably unrelated) code. I find it also helps me to think in tune with the new language as well, rather than fighting against it.

But yes, it's certainly worth revisiting coding practices periodically. If you can't decide why something's a good idea, try doing without it for a while...

Answer 2

Accidental assignment protection:

Putting the lvalue on the right hand side is not needed in some newer languages like C#.

In C# the following won't compile:

if (variable = 0)

So in C# there is no need to do:

if (0 == variable)

This practice is very common in C/C++ programs to avoid accidental assignments that were meant to be comparisons.

---

Multiple return points:

Disallowing multiple return points was enforced mainly because you don't want to forget to delete your variables.

Instead if you just use RAII you don't need to worry about it.

Disclaimer: There are still good reasons to minimize multiple return points, and sometimes it is useful to have only one.

---

Header files

In most modern languages, you do not separate your code into declaration and definition.

---

C++ defines for multiple header file includes

In C++ you used to often do:

#ifdef _MYFILE_H_
#define _MYFILE_H_

//code here

#endif

This sometimes would lead to something like the following though:

#ifdef _MYFILE_H_
#define _WRONGNAME_H_

//code here

#endif

A better way to do this if your compiler supports it:

#pragma once

---

C variable declarations

With C you had to declare all variables at the top of your block of code. Even later versions of C didn't require this though, but people still do it.

---

Hungarian notation: (Read, contains some unique info)

Hungarian notation can still be good. But I don't mean that kind of hungarian notation.

Before it was very important in C to have things like:

int iX = 5;
char szX[1024];
strcpy(szX, "5");

Because you could have completely type unsafe functions like:

printf("%i", iX);

Now if I would have called the string x, my program would have crashed.

Of course the fix to this is to use only typesafe functions. So as long as you do that you don't need hungarian notation in this sense.

But still it is a good idea as discussed by Joel in his sense.

Answer 3

I used to separate all my line numbers by 10, starting each logically separate piece of code at intervals of 100 or 1000 i.e.

10 Print "Hello"
20 Gosub 100
30 'Peeks and Pokes

For obvious reasons, I no longer code like this.