Grumpy old fart

Self taught Access, Excel, Word, Powerpoint, Visio VBA and Visial Basic 6 guru. I have used all the programs since their invention - started out in DOS and Qbasic and yes, I even remember when computer programs had to be loaded on punch cards in FORTRAN

Retired military (21 years), currently working civil service. I have several complex Access databases under my belt (10's of thousands of lines of VBA code each)

I am willing to help any and all who need it, but you should attempt to research the solution first yourself - best way to learn is to scratch your head and sweat over it for a while.

Neat code is good code. Don't skimp on proper declarations and don't use one-line If statements - those just piss me off. And don't ask me to do your homework you lazy #$%^&&* - do it yourself!

If you do have a legitimate question though, please ask. I might even write a paragraph or two of code for you - I love a challenge.

Just consider me the Dr. House of VBA. If you need a diagnosis, ask - it's what I do, but don't expect to be coddled and hugged!

Good to have you aboard! VBA help is always welcome.

don't use one-line If statements - those just piss me off. And don't ask me to do your homework you lazy #$%^&&* - do it yourself!


sounds like retired military to me!

sounds like retired military to me!

Retired military (21 years)

ajetrumpet, I assume that you are not working in the investigative/intelligence professions.:D:D

As a VB6 veteran myself, I have always wondered how others handle the fact that it does not have its own report designer module of note. I have used Active Reports as an addin, I have also used Access to produce complex reports. However this limits the use if Access is not installed on the host machine.

What approach have you adopted for report generation from within VB. Using Crystal Report is one option, but again users ned to have the software on their machines.

Whats the problem with one line 'if' statements? Why write three lines when one will do?

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 am willing to help any and all who need it, but you should attempt to research the solution first yourself - best way to learn is to scratch your head and sweat over it for a while.

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.

Actually, this is quite humorous from a non-Access perspective too. I would periodically get calls from students who were preparing to take their professional certification exams (Architecture as one example). The typical call: "the exam is tomorrow, there are questions concerning building in the coastal zone, what can you tell me?" As with many questions, the answers are not simple.

Well, what had the university been teaching these kids for the past 4 years?:confused:
One would assume that the kids would know what would eventually be on the exam, they also had four years to prepare? :confused:

Sigh, I guess the story is the same for every profession! Makes you wonder about our technical competence.

ajetrumpet, I assume that you are not working in the investigative/intelligence professions.:D:D

Of course not. I'm only 29. isn't there an age criterion for this? There's also probably a "jerk" meter than has to be satified as well. Either that, or a "politically keen" measurement that must be met. Oh wait...I better not say that huh? Lest I insult another member... :eek:

What approach have you adopted for report generation from within VB. Using Crystal Report is one option, but again users ned to have the software on their machines.

Reporting Services. ;)

Doc's comments on comments brought back memories, yes we had guys who churned out Assembly code without comments, I made them document it before signing it off.
I remember attending a seminar headed by a senior guy from Ferranti back in the 60s and he told a tale of a member of staff who had asked for help on an undocumented program, his excuse was that it was only going to be run once, the response , "well you've had your one run so go and throw it in the bin". It was probably apocry, bugger it, made up but it illustrated a truth.

BTW you guys aren't old yet.

Brian

BTW you guys aren't old yet.

BrianWe always wonder how old Brian could be. But I guess we would never know :p:)

Whats the problem with one line 'if' statements? Why write three lines when one will do?

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.

C, K & R:
if (i>0) {
...
}

C#, Allman:
if (i>0)
{
...
}

VB:
If i>0 Then
...
End If

A case can be made that we could make the "End If" less verbose but that would go against the design goal of VB - to make it readable. This is especially when we're dealing with deeply nested blocks:

for(int i, i=100, i++) {
if (i>0) {
do {
i++;
} while ((i % 10) != 0);
}
}

Contrast to VB:

For i = 0 to 100
If i>0 Then
Do
i = i + 1
While (i Mod 10) <> 0;
End If
Next

While the example are simplistic, it's quite very easy to see which block we're dealing whereas it's very easy to get lost in which {} blocks we're looking at because they are used for all kinds of branching whereas VB give an unique identifier to every kind of branching block so modifying code with several of block is relatively easy in VB.


Finally, just because Perl programmers can do it in one line, doesn't mean it's going to be fun revising it months ago. There's a reason why they tend to consider Perl to be "write-only" language.

We always wonder how old Brian could be. But I guess we would never know :p:)

I'm just a youngster as indicated in my profile. I walk twice a month with the U3a and during our short walk ,7-9 miles, we have lively discussions, I'm the baby of the bunch, well almost.

Brian

A retired youngster with grand children and a wealth of knowledge. You accomplished all at a very tender age. Niceeeee!!

I'm trying to figure out what Banana's post had to do with Chergh's.

Brian

As long as no one tries to do things in APL, we are good. Now THERE was a language that had more one-liners than Henny Youngman or Jeff Foxworthy.

What approach have you adopted for report generation from within VB. Using Crystal Report is one option, but again users ned to have the software on their machines.

When I need reports in a strictly VB6 environment I either output the info to a Word document (and yes, I have to do ALL the formatting, etc in code) or to an HTML document (Nearly everyone has a browser installed and can view a web doc). I've used Crystal Reports, but was never really enthused by it. In recent years I've been working mostly in Access, so reports haven't been an issue. I have found as a general rule, the less choices most CASUAL users have, the better they like it, and the easier they percieve the program to be, so even though it might take a bit of coding, as long as I talk to the end user and get them what they need, once it's designed well and the users like it, having little or no choices for output hasn't been a probelm - for me. It all depends upon your endpoint customer and what they want.

Whats the problem with one line 'if' statements? Why write three lines when one will do?

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. Plus, I'm a stickler for consistancy, so I don't like a mix of multi-line IFs and one-line IFs. Kind of a self discipline thing - you either smoke or you don't, no gray area - you are either pregnant or not, no in-betweens - and you either adhere to consistant coding standards or you don't, no in-betweens.

I'm trying to figure out what Banana's post had to do with Chergh's.

Brian

As embarrassing as it is, it looks like I took chergh's question the wrong way - at that time, I thought he was asking "why VB is so verbose?" but now I see he was asking smithwick why he didn't like it.

Need to 1+ my reading comprehension. Apologies.

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?

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:

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.

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."

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

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."