Visual Basic Coding conventions

I recall having spotted a thread on this forum where one poster declared to his bewilderment that he actually sifted through synonyms from the Thesaurus before he dubbed his routines. I found something amusing and similar to that post in here:

http://www.freevbcode.com/ShowCode.Asp?ID=2547

<EXCERPT>
6.    Thesaurus Surrogatisation
To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean write to a file, and to a print on a laser, and to display on the screen). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be unprofessional breach of the structured design principle of information hiding.
</EXCERPT>

Sathyaish Chakravarthy
Wednesday, November 19, 2003

I often fire up Microsoft Word and hit Shift-F7 on a term to find synonyms in order to draft up my function or class names.  Sometimes it's also necessary when looking for the right term to display to users.

Almost Anonymous
Wednesday, November 19, 2003

Fantastic ! One of my favourite quotes:

"Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack."

heh.

Kentasy
Wednesday, November 19, 2003

That would be preferable to variable names like:

index
flag
var

An, to reuse the same variables with in subroutine for different purposes.

I am in the midst of debugging someone else's code and I wish he had a thesauras.

pdq
Wednesday, November 19, 2003

Kentasy, I too had a lot of funning reading through the document. I recall Bruce McKinney also quoting in Hardcore Visual Basic (Chapter 1, Sub-Topic: Naming Convention) about the obfuscating nature of the orthodox Hungarian Notation, if followed to a point of insanity. Its evenly spread all over the publication.

Amoung all the rest of the stuff, I like this one very much:

<QUOTE>
Buy a copy of a baby naming book and you'll never be at a loss for variable names. Fred is a wonderful name, and easy to type. If you're looking for easy to type variable names, try adsf.


ccented Letters
Use accented characters on variable names. E.g.

typedef struct { int i; } ¡nt;
where the second int's i is actually iacute. Since these are structures the three int's are not interchangeable, but with an 8-bit aware editor it's nearly impossible to distinguish the slant of the accent mark. Insist the new "ints " are for some specific, but very obscure, situation where a standard int won't suffice. It helps to toss extra stuff into the structure before making that claim!

Extended ASCII
Extended ASCII characters are perfectly valid as variable names, including á, Ñ, and ¤ characters. They are quite impossible to type without copying/pasting.

Lower Case l Looks A Lot Like Digit 1
Use lower case l to indicate long constants. e.g. 10l is more likely to be mistaken for 101 that 10L is.

Documentation
Any fool can tell the truth, but it requires a man of some sense to know how to lie well.
Samuel Butler (1835 - 1902)


Incorrect documentation is often worse than no documentation.


Document the obvious
Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method

Gotchas
Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper in the movie Bambi "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired. An anonymous comment that says "This needs to be fixed!" can do wonders, especially if it's not clear what the comment refers to. Keep it vague, and nobody will feel personally criticized.

Be polite, Never Assert
Avoid the assert() mechanism, because it could turn a three-day debug fest into a ten minute one.

Use Three Dimensional Arrays
Lots of them. Move data between the arrays in convoluted ways, say, filling the columns in arrayB with the rows from arrayA. Doing it with an offset of 1, for no apparent reason, is a nice touch. Makes the maintenance programmer nervous.


Wrap Wrap Wrap Some More
Make sure all API functions are wrapped at least 6-8 times, with function definitions in separate source files.


No Secrets!
Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can't very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces


Testing
I don't need to test my programs. I have an error-correcting modem.

Om I. Baud

Leaving bugs in your programs gives the maintenance programmer who comes along later something interesting to do. A well done bug should leave absolutely no clue as to when it was introduced or where. The laziest way to accomplish this is simply never to test your code.

Testing is for cowards
A brave coder will bypass that step. Too many programmers are afraid of their boss, afraid of losing their job, afraid of customer hate mail and afraid of being sued. This fear paralyzes action, and reduces productivity. Studies have shown that eliminating the test phase means that managers can set ship dates well in advance, an obvious aid in the planning process. With fear gone, innovation and experimentation can blossom. The role of the programmer is to produce code, and debugging can be done by a cooperative effort on the part of the help desk and the legacy maintenance group.
If we have full confidence in our coding ability, then testing will be unnecessary. If we look at this logically, then any fool can recognize that testing does not even attempt to solve a technical problem, rather, this is a problem of emotional confidence. A more efficient solution to this lack of confidence issue is to eliminate testing completely and send our programmers to self-esteem courses. After all, if we choose to do testing, then we have to test every program change, but we only need to send the programmers to one course on building self-esteem. The cost benefit is as amazing as it is obvious.


Your Boss Knows Best
If your boss thinks that his or her 20 year old FORTRAN experience is an excellent guide to contemporary programming, rigidly follow all his or her recommendations. As a result, the boss will trust you. That may help you in your career. You will learn many new methods to obfuscate program code.


Book Of The Month Club
Join a computer book of the month club. Select authors who appear to be too busy writing books to have had any time to actually write any code themselves. Browse the local bookstore for titles with lots of cloud diagrams in them and no coding examples. Skim these books to learn obscure pedantic words you can use to intimidate the whippersnappers that come after you. Your code should impress. If people can't understand your vocabulary, they must assume that you are very intelligent and that your algorithms are very deep. Avoid any sort of homely analogies in your algorithm explanations.


Visual Basic Madness
If reading from a text file, read 15 characters more than you need to then embed the actual text string like so:

ReadChars = .ReadChars (29,0)
ReadChar = trim(left(mid(ReadChar,len(ReadChar)-15,len(ReadChar)-5),7))
If ReadChars = "alongsentancewithoutanyspaces"
Mid,14,24 = "withoutanys"
and left,5 = "without"



</QUOTE>

>That would be preferable to variable names like:

>index
>flag
>var

ROFL

>I am in the midst of debugging someone else's code and I wish he had a thesauras.

I hope the coder who's code you are fixing isn't on the list of contributors in bottom of the page mentioned in the URL link above.

Sathyaish Chakravarthy
Wednesday, November 19, 2003

Holy crap! I dunno how that hell of a pseudo-gerund got there.

>Kentasy, I too had a lot of funn*ing* reading.

Extremely sorry for the typo. Am not *that* bad.

Sathyaish Chakravarthy
Wednesday, November 19, 2003

No poblerm. I mkae tpoys all the tmie.

Kentasy
Wednesday, November 19, 2003

Me two, but not generically in pubic.

Thursday, November 20, 2003

  Recent Topics

  Fog Creek Home