Bad Programming Habits

[metra]

I've got some questions as to what habits you would generally consider "bad".

1)One common thing is bracket (or braces) placement.

while(x==5){

or

while (x==5) //Included a space here, too.
{

I like the first one since having a whole space for the bracket seems too, i dunno, space consuming.

2)Documentation. How often do you do it? I dont really like it since i know exactly what my program is, but i guess it would be more helpful for my teacher. But I would only document if i'm showing the program to someone who doesnt catch the drift of a program quickly.

3)Naming variables. I always use the shortest variable name possible. No underscore or capitalization. Takes too long to press shift and the underscore key. Sometimes i just use a,b,c,d as variable names for counters. But now, im using a,b,c,d less and less. =]

4)LOOOONG parameters. For one function i had like 8 parameters. It was the only way i could find that maybe the program most efficient. =[

5)Break and continue. I use break, a lot. Not too much with continue though.

6)Switch. It doesnt work for most cases so i just use a bunch of if's. Switch is pretty elegant though.

7)Just thought of this: If you have an if that doesnt require brackets (one line) then i guess you can write it like this:
if(x==5) y=3;




Anyone else who knows any "bad habits" and would like to add them to discuss can do surely add them. What are your opininons on the ones i listed? I dont think theyre that bad.

Btw, do colleges reject your work if its not their programming style?

 

[naif]

Yo hmm, I dont think colleges will have any problems, but you can never predict. Anyways, Variable naming is very important. If you use variable names like a,b,c,d atleast place a comment at the place you declared them stating the purpose of these variables.

About the while() { thing, both are used and none of them is a bad habit(same goes for the if() statement braces thing). About breaks and continue's, they are also used a lot in structured programming. Using of goto's and all is not recommened though and using them wouldnt also be considered structured programming.

And whats the reason your switch statements dont work? Common mistakes made in the use of the switch statements are as follows, first of all remember, you can only use int and single char data types for use with switch statements, I dont know if we would use float/double or not though.

Here's first mistake many people make sometimes

char x = '0';
swtich(x)
{
case 0: blah blah blah;break;
//etc etc
}

As you see, the value you assigned to the variable x was '0', Its the character 0, not the decimal value 0. The character '0' is actually the ASCII value 48. The correct code would had been to look for a '0', not just a 0.

case '0': blah blah blah;break;


Lastly, about Documentation, sometimes even an expert might be confused as for what you are trying to do somewhere in your code. Its possible you made a mistake in your code, and when the person viewing your code see's that, he might think of it as a feature because in somecases he too might be clueses for as to what you were trying to do at that place. Sorry no examples for this

 

[Thelemac]

Ever go back to a program that you've worked on?

You'll hate yourself for not having documentation then.

 

[NookieN]

I say to hell with "proper" programming style. While I definitely think readable code is important in most cases, my personal belief is that efficiency and functionality should always be placed before beautification.

Placement of braces and parathesis is almost completely irrelevant to the compiler. Variable names should be meaningful to you but also be something you're willing to type again.

Documentation is a matter of perspective. If I think I won't be able to remember what I'm trying to do with a piece of code, I'll make a short comment. If I'm certain someone else will have to maintain the code I might make a more detailed comment. The thing is, if you work with truly smart people they won't care about your comments. They will figure out what your code does whether you comment it or not.

With that in mind, I'd say comments in course assignments should be as short and meaningless as possible.

 

[metra]

You all have good points, i guess. And for the switch statement, i was assigned a program that incorporates the funcition <ctype.h>. It has a bunch of functions that check if a character is uppper case, lower case, a digit, a number or letter, and a blank. I couldnt figure out an efficient way of using switch so i just said to hell with it and used a bunch of ifs. What i meant in my first case is that switch doesnt work instead of situations that use a lot of ifs.. i think.

Most of the programs i have done are pretty short... One - two pages with simple objectives. Therefore, i'd know what its about. But i could definately see the pros of good documentation.

Anyone know any other bad habits?

 

[CKY WC]

i jet an auto 20% taken off if i turn my BV work in not properly formated

 

[Itchie]

What about goto statements?

Every professor I've had says not to use them. But a while ago I was writing a program and I used a goto statement because it made my program much more efficient than if I had done it another way. Anyways, my prof deducted a few marks for it. So when I asked him why, he said goto statements are "bad programming practice". I asked why, but he wouldn't explain, he just kept repeating never to use them because they're bad programming practice.

I think that's kind of dumb. I know that all programming tasks can be accomplished without goto statements, but still, if you have a situation where it will make your program more efficient then why not use it?

 

[naif]

Even if goto's do simplify some stuff, still their usage is considered as unstructured programming. And most of the time goto's can be a very big pain to follow while going through a source code so I would say its better off to avoid them. And about efficiency, I cant see anything in them which can make your program more efficient.

 

[XWRed1]

Its funny in assembly, you have to use gotos to implement the higher level structures like if statements or while loops or whatnot. They don't look down on them at that point

 

[Itchie]

Sure goto statements make a program hard to follow if you use them all over the place. They should not be used excessively, but there's nothign wrong with using them in the perfect situation. Same with break and continue.

Was assembler hard to learn? I tried to teach myself when I was about 14 but I gave up.

 

[XWRed1]

I think its pretty simple, just tedious.

 

[JigPu]

Sure goto statements make a program hard to follow if you use them all over the place. They should not be used excessively, but there's nothign wrong with using them in the perfect situation. Same with break and continue.

Ditto. I come from a programming background of BASIC (...where GOTO's are most abused), and I must say that I find nothing "unstructured" about using GOTO when nesscary.

If you are using GOTO excusivley (instead of FOR loops for example), then it can be hard to read. Not much harder than a FOR loop (as long as you tab in the repeated code like normal), but still not good for the reading.

But there are some situations that I have had to think for about a half hour to come up with a way to NOT use a GOTO simply because the prof hates them. I mean, sometimes, you just need to go somewhere completely different, and a subroutine just dosen't fit the bill for some reason.

JigPu

 

[NookieN]

Here's another observation from experience: all the comments and "proper" coding style in the world won't help you that much when your algorithm is wrong. Good debug messages can save you though.

When I'm coding I try to make error and debug messages as detailed as possible. Printing "I got here" isn't gonna cut it. You're better of printing "Reached inner loop with value VAL, outer loop value VAL", or "Or couldn't copy file FILE1 to FILE2."

Of course this is Perl pragma since erroring-out is pretty painless in Perl. But even in C/C++ you're ahead to put debug statements in at first and comment them out later than to go back when you're trying to figure out which lines out of 600 (or 6000) aren't working.

 

[Guid0]

OMG i am a tutor in my programming lab and you wouldn't believe the s**t that the people bring in......my favorite is the ones who type out thier entire progs in notepad then bring it in and compile it for the first time and then whine and btch about how many errors they got.......the there are those that condense 4 pages of code into one page.....looks like a paragraph no spacing at all......oh errrrrm


1)One common thing is bracket (or braces) placement.

while(x==5){

or

while (x==5) //Included a space here, too.
{

I like the first one since having a whole space for the bracket seems too, i dunno, space consuming.

a: I like #2 makes it easier toread each scope and harde rot forget to close your blocks

2)Documentation. How often do you do it? I dont really like it since i know exactly what my program is, but i guess it would be more helpful for my teacher. But I would only document if i'm showing the program to someone who doesnt catch the drift of a program quickly.

a:there shouldn't be an answer to this. you shouldn't ask how often or how much.....you should document when you need it....good example here.......i was running a server from a redhat box to stream MP3's around the house...well some of the prog didn't exactly like i wanted so i tackled the src code....THANK GOD FOR DOCUMENTATION!!!!

3)Naming variables. I always use the shortest variable name possible. No underscore or capitalization. Takes too long to press shift and the underscore key. Sometimes i just use a,b,c,d as variable names for counters. But now, im using a,b,c,d less and less. =]

a:why are you using this variable?....what is this variable for? have you ever been asked either of those questions....man i sure as heck know i ask them alot


6)Switch. It doesnt work for most cases so i just use a bunch of if's. Switch is pretty elegant though.

a:Maybe you just haven't found a good use for switch yet....hard to believe yet

7)Just thought of this: If you have an if that doesnt require brackets (one line) then i guess you can write it like this:
if(x==5) y=3;

a: guilty---sometimes we are hurried....LOL

 

[garwain]

GOTO: I've never found a place where I have needed to use it. I've seen programs that use GOTOs for everything, and told the author to forget about having me debut it.

or the braces I prefer the style
if(x==y)
{
do_something();
}

I find this layout is easier to read because it spaces the program out better.


Documentation: Where ever it's needed. I usually put a line or 2 in if I can't figure out what is going on when I just glance at the code.

Variable naming. I'll usually give variables a name that will help document the code, but I'll usually use either x,y or z for counters and i indexes.

If I have a function that requires a lot of info, I'll usually design a datastructure to hold the info, so that I only have to pass one or 2 parameters.

One thing that I've seen that I really hate is when people condense code to the extreme

DrawForm(getval(currentUserRec, 'SIN'), formID);saveForm(formID); printform(formID);closeform(formid);

I remember a friend passing me something like that at college for a group project. I spent an hour spacing out his code before I even started to try to make it work with the section I had written..

For me, the most important things for good code are
1) keep it readable
2) keep it understandable
3) keep your style consistant

 

[macklin01]

The points above are really, really great.

Speaking as a guy who does scientific computation and writes routines that take dozens of source files, each with hundreds to thousands of lines, I can definitely say a few things here:

1) documentation isn't just nice -- it's essential! Especially if you're changing a line of code to see how it works.

example:

// dTemp = cos( (pszArg[1]) ); // dumped on 4-2-2002
dTemp = cos( (double) (pszArg[1]) ); // tried on 4-2-2002

2) while( dBlah <= 52 ) { \\ ....
}
vs
while( dBlah <= 52)
{
\\ ....
}
Using consistent indentation helps debugging immensely. Putting each open bracket at the same horiz. spacing as each close bracket is best, in my experience. Also, as mentioned above, it helps in determine which variables are in which scope.

3. Naming conventions. I think that consistent naming conventions are essential, and having descriptive names is better than not. I got some code to implement from a colleague about a year ago for solving 3-dimensional advection equations. It had no comment lines, and everthing was named a, b, c, d, e, .... etc. It made no sense! My personal rules:

dBlahBlahBlah : a double variable
nBlahBlahBlah : an integer variable
szBlah : a string
pdBlah : a pointer to a double
bBlah : a boolean variable

bool bFinishedTesting is much more helpful than bool b.

Notice then, too, that you don't lose track of whether something is a double or an integer, and you can have integers and doubles with the "same" name.

I hope that this is helpful. Thanks for bringing up the great topic! -- Paul

 

[metra]

Today I showed a program to my teacher and she didnt even look at it because I only had 1 function! The function was about a page long. She said that I would have to edit it so that there are several functions. I tried to reason with her but she wouldnt accept. I do not see a point of this! My function is neatly spaced out and easy to understand. If i divided it up, then the there would be several functions consisting of 2-3 lines! Maybe even 1 line!

Btw, I didnt think that you can have arrays as function parameters because when I attempted to do " void score(dicelevel[12]) " an error appeared. This was one of the reasons that I had that long function. However, i found my error and fixed the function a little.

This, however, still doesnt compensate for the fact that she wants several little 1-3 line functions! IMO, this is ridiculous! Laziness defeats elegance in this situation.

Anyway, what do you guys think? Am I right or am I wrong?

 

[Cowboy Shane]

Anyway, what do you guys think? Am I right or am I wrong?

In my opinion, you are wrong. A function should only do one thing, and contain only enough code to accomplish that one thing. For instance, a function to open a file should only open the file providing whatever error detection needed. It is not that functions duty to begin processing the file.

It could be argued that the error correction should be another function, and that is how I would do it, but I'm trying not to go overboard on you.

I've had many instructors who would count off for having a function that becomes to much like a swiss army knife.

 

[macklin01]

Teacher's right, although being so harsh maybe isn't. (But how else do we learn?)

Compartmentalizing code (and encapsulation) is a key concept. It helps in breaking code down into functional pieces. For example, one function searches the user input for option flags. Another decides which function to call base on the flags. Another might display data in a specified format. Another might write a data set to a data file. (in a pre-arranged format.)

Let's say you display your data several times througout your code. Then, let's say that you don't like the display format, and you'd like to change it. Without functions, you have to change it each and every place, and make sure each time is identical. With functions, you just modify the function. Etc.

Now, as for arrays. You might want to do something of this nature: (let's say it's an array of doubles) The key idea (in case there's a typo below) is to make it a function of the memory address of the array.

void FunctionName( double *pdDoubleArray, int nSize)
{
int i=0;
while(i < nSize)
{
cout << i << ": " << *(pdDoubleArray+i) << "\n";
i++;
}
return;
}

Here's another way: (I tested this. Apparently, it will let you edit data within the function and have the changes persist, as it's actually passing the array by reference)

void FunctionName( double dDoubleArray [], int nSize)
{
int i=0;
while( i < nSize )
{
cout << i << ": " << dDoubleArray << "\n";
i++;
}
cout << "\n";
return;
}

 

[Cowboy Shane]

As an added bonus, just wait till you start writing classes since then you will have a lot of one or two line functions to write.