Joe Miller Good Coding Practices? 5

[jebry]

Hi Joe Miller!

I saw your post and, as you can probably tell from my posts, I am pretty new to the programming game. Could you please explain what you meant about good coding practices? Is there a good book or Web site that explains coding practices? I am a very good problem solver, but I want to learn all I can about programming and this is an area I have no experience in. Any help would be appreciated.

Jeff Bridgham
P.S. If anyone else reads this post and has comments, please don't hesitate to help!

 

[JoeMiller]

Hahah . . a major can 'o' worms!! Good coding practice is something you learn as you work, and learn from books, and learn from inspecting others code as well as your own.

It's really done to make it easier for you and other programmers to go back and understand what you've created and be able to pick up where you left off quickly. It makes it easier to comment code, because the code can do some of the talking for you instead of reading verbose comments. IMHO, it looks cleaner, though is often longer. The increased length is the main reason many programmers don't do it a lot or at all, it takes too long to type it out and they figure "Why? The compiler will know what I mean..." Which is often correct, but it's not for the benefit of the compiler, it's for the benefit of others inspecting your code.

Basically what I try to do to follow "good coding practices" is always declare variables, use descriptive names, put clues to what kind of variables they are. For instance, strMyVariable you know is a string right away but what if it were called MyVariable, now you have to go back to the declaration and find out what kind, well what if it's not declared?? Then you've got no idea! It makes it harder to troubleshoot. This BTW also applies to table names, query names, form names, control names, everything! I personally use the Reddick VBA naming/coding conventions (

http://www.xoc.net/standards/)

when designing db's and writing code. It takes extra time, but pays off when you or someone else has to work on the project in the future, and helps in development because you have meaningful names instead of the access Table1, Query1, List1 crap.

The other things I try to do is use proper syntax, there are many shortcuts to referring to objects. Pick one and stick to it, some programmers go in between the different ways to refer, they'll use:

[tt]Me("ControlName&quot[/tt]

one minute and then

[tt]Me.ControlName[/tt]

the next. Not a big deal, just when you see the two it makes you wonder "Is there a difference?!"

And one of the other things I try to do is always put what I'm testing for down explicitly and supply all arguments, even many optional ones. Many function return True/False. Well for many functions when you put the function not followed by "=True or =False", True is assumed. While this works, it's not very clear. IE:

[tt]If IsNull(x/y)=True Then[/tt]

instead of

[tt]If IsNull(x/y) Then[/tt]

it's longer yes, but it's easier to understand what's going on. Some functions may default to false so then you're left wondering is this a false function or a true function? By always putting it in, necessary or not, you know right away.

There are many other things, but these are some of the bigger things I try to achieve when coding. Others will differ GREATLY in opinion on this. You'll start to see where you falter in this when you review your own code against others. Most books subscribe to the convention above, and from the examples in them you'll start to get an idea of "good coding practices". They don't come overnight, they do increase development time, they do make your program easier to understand, fix, & troubleshoot. Take it or leave it, hopefully that helps! Joe Miller
joe.miller@flotech.net

 

[jebry]

Joe,

Thanks for the reply the hints you gave look to be very useful! I bookmarked the web site you gave because there is no way I am going to read that in one sitting!

I'm also going to pass it around my office. It's hard to get things changed at a University, but there is no harm in trying!

Thanks again
Jeff Bridgham

 

[Rhonin]

Thanks for the great example.

As a "follow-up" programmer, I am called upon quite often to fix a problem or to enhance existing code. There have been many a time I have found it easier to rewrite the code from scratch than to go back and attempt to figure out exactly what it was the previous individual was trying to do.

Comments ARE A NECESSITY! IMHO that one thing needs to be followed more than any other item.

BTW, good luck and best wishes.

 

[TheInsider]

There are many different prefixing methods out there, but you can obtain a list of Microsoft's official prefixes entitled "Hungarian Notation" here:

http://support.microsoft.com/support/kb/articles/Q173/7/38.ASP

Rob Marriott
rob@career-connections.net

 

[grnzbra]

Make comments meaningful. One company for which I worked had comments like this:

********************************************************
* If A = B then C = D else C = E
********************************************************
If A = B Then
C = D
Else
C = E
End If

Why bother having a comment at all, but there they were; one comment like this for almost line of code. Also, it might make more sense if it read:

********************************************************
* If sex is "Male" assign him to the men's dorm, otherwise
* assign her to the women's dorm.
********************************************************
(By the way, this was using a different language that limited variable names to 8 characters, so they couldn't be
too descriptive.

 

[fneily]

As implied above, as you mature in programming, you're coding should become cleaner, efficient and concise. Of course, this depends on the person. I had a peer at AT&&T who was into negative logic. Instead of testing for the state of New York, he actually tested not Arizona, not Arkansas, not Alabama, etc... It probably isn't a suprised that he liked his "gangi".
And don't forget to RTFM. Programer talk for Read The F Manual.

 

[LogicalmanUS]

JoeMiller is just so right.
I have been using the Reddick VBA naming and coding conventions for some 7 years or so, and can say that it has assisted me in going back to code I wrote 5 years ago, and still being able to understand it again!!!
Good REMarks are also essential. Explain why you use the code if there is another, more likely, way of coding it (some other poor person may need to edit this later!)

For a larger Access Project, I tend to keep my variable declarations in one Module, separate from other modules, and also I tend to use Global Modules rather than Class Modules. It takes a little longer when referencing a form (using a Form variable) but it's worth it. You can use Functions and variables in these modules that can be accessed by other forms.

Congratulations and welcome to the world of programming, and remember, the most important piece of equipment is either a good coffee maker, or a fridge to hold the high caffeine sodas!!

Logicalman