Grrrr!! Grumpy old fart here (1 Viewer)

Banana · Apr 7, 2010

c_smithwick said:
It's a personal thing. I have written an add-in that I use to format all of my code, and one-line IF statements give it nightmares.

Do that mean you don't like the default formatting that VB editor uses or that you don't use VB editor?

c_smithwick · Apr 7, 2010

The_Doc_Man said:
Since this isn't Visual Pascal, a one-line IF statement that includes a GOTO should be perfectly acceptable. A one-line IF/variable update is probably not a bad thing, though there is issue in readability for maintenance. A one-line IF/GOSUB is a trap waiting to trip you up.

As to the grumpy old fart... I've been accused of being full of beans myself, so I understand the mentality. Don't worry about telling newbies that we don't do their homework for them. I'll be right next to you on that concept. Although to be honest, if I were farther away from retirement, I'd actually help the dum-dums more so that when it came time to compare skills at job interviews, I'd win every time.

I'm rather surprised you didn't jump all over another thing that is my personal bete noir - VBA comments. Some of the kids who churn out code by the barrel-full don't comment anything.

One of my first "real" jobs was to rewrite a utility that was acting up. Nobody could maintain it because it was assembly code that was written COMPLETELY without comments, and it wasn't a short program, either. When I became a supervisor, I told every one of my staff members that I would review their code and if it didn't have MEANINGFUL comments, I would skewer them and roast them over an open fire.

But then, I learned a lesson from a friend a long time ago. When you are doing anything of merit and complexity, don't trust your organic memory. Use comments. Or if you have nothing else, use a damned pencil and paper until you can organize your comments.

I must confess, I'm a limited commenter myself, but I've found that if I stay VERY consistant with coding standards and write good, clean, consise and clear code that commenting requirements remain at a minmum anyway. For instance, if you write a function:

Code:

Public Function reFormatString (strInput as String, intNumberOfLetters as Integer) as String

Is it really neccesary to write a comment line describing the functions purpose, inputs and outputs? Seems kind of obvious to me. As for comments inside the function itself, I'm probably guilty of too few, but if I am redistributing my code to anyone else but me to read, I will go back and add clarification comments where appropriate. But, as a rule, I try and write the code so it's very clear what's going on - at least to anyone except maybe an ULTRA novice, so the commenting requirements stay minimal.

c_smithwick · Apr 7, 2010

Banana said:
Different languages and different styles may some say on it but for anything that's more than a simple increment or like almost to be always spread into more than one lines, so it's not a VB thing.

Things other than one-line IFs piss me off too, but I won't enumerate them all here. Bottom line my philosophy has always been if it's worth writing, it's worth writing right. If you are too lazy or rushed to split your declarations into separate lines or declare your variables as "strThis String As String" instead of "s As String", then you need to get up and quit programming. My father had a saying that I've come to live by, "If you are going to do it, do it right the first time. Doing things half-assed is just as bad as not doing it at all."

Brianwarnock · Apr 8, 2010

2 things that piss me off are
1 People who don't read the spec
2 People who don't test

Which one applied in the Time on Job thread?

Brian

The_Doc_Man · Apr 8, 2010

Is it really neccesary to write a comment line describing the functions purpose, inputs and outputs? Seems kind of obvious to me. As for comments inside the function itself, I'm probably guilty of too few, but if I am redistributing my code to anyone else but me to read, I will go back and add clarification comments where appropriate. But, as a rule, I try and write the code so it's very clear what's going on - at least to anyone except maybe an ULTRA novice, so the commenting requirements stay minimal.

Perhaps I've been working in the industry too long, but also I've been working for the U.S. Dept. of Defense (indirectly) for 20+ years. They have standards about entry-point documentation, exit-point documentation, and at least "paragraph-level" documentation. I.e. small sequences of code related to a single computed result.

Further, having been burned by non-commented and poorly-commented code too often, I tend to be strict about "self-documenting" code. In essence, even when working in COBOL {gasp}, there is no such thing.

My rule when I was a supervisor of a development team working in assembly and in high-level code was simple. On every code sequence that did something related to output data, one comment per output field. On every code sequence that took a few lines to compute some final result but maybe had a couple of intermediate statements, one stand-alone comment like "Next 5 lines build the output shipment-size string" (or whatever was being built) for every logically-related code sequence. For every entry point, name the variables INCLUDING LIMITATIONS and describe options. For every exit point, summarize the meaning of each returned value.

Now, I agree with you on something very important. Whatever you choose for a standard, stick with it. But I would qualify that by adding "if it is a good standard and your customer is willing to accept it."

Grrrr!! Grumpy old fart here (1 Viewer)

Banana

split with a cherry atop.

c_smithwick

Underpaid Programmer

c_smithwick

Underpaid Programmer

Brianwarnock

Retired

The_Doc_Man

Immoderate Moderator

Similar threads

Users who are viewing this thread