Which Is Better Coding?

[Jonmo1]

Not sure what else to say.
You've gotten overwhelming responses to your question.
It's clear you have your mind made up, and no-one's going to change it.
And I don't think you're going to change anyone else's mind either.
So We're at an empass.

 

[peterpre]

I think Peter has to be trolling, at least partially.

But on a related-to-formal-programming note, what type of environments do professional Excel-VBA programmers typically work in-- as consultants or within a large corporation? Is their a concentration in any particular industry? Are the applications predominantly front-ends to databases (SQL/Access)?

Do corporations have IT-help positions related to solely Excel?

I am seriously not trolling at all. And I think my question goes beyond just Excel-VBA programming.

Quote understandably, the convention is towards consistent variable naming and explicit comments.

All I am saying is that it has gone too far, so that in the small number of cases where such effort is not necessary, people still waste time following this convention.

 

[taurean]

AA] Maybe this analogy shall let you decide:

At some of the traffic junctions, you see RED signal and you stop. And you see no one is crossing and mutter to yourself, what a waste of time, bloody waste of time indeed.

But that is the thumb rule that you are supposed to follow and someday, when a mishap occurs, following signals seems justified.

BB] In an environment, where more than one people are working on the same project, it actually pays off to have a convention and sticking to it for obvious errors and mixups.

CC] If you are doing it alone and probably you are the only one who is going to look after then perhaps you can cutdown as you want to. A chinese saying goes like this: Faded Ink is thousand times better than Sharp Memory. It roughly means the typing overload and waste that you feel you are doing now will come in handy otherwise you will be playing Sherlock Holmes for hours with your own code with No Watson around.

DD] Commenting is useful when you are using a new technique which you feel you won't remember next time when you open it. So don't do it like plague either that your code starts looking GREEN literally. But a dash of green will always help.

My 2 paise on this!

 

[peterpre]

Overheard conversation last Wednesday at the “Post Road Tavern”…
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" /><o></o>
- So how’s business?<o></o>
- Pretty good actually – we’ve just got rid of some of our old processes and we’re saving a lot of wasted time.<o></o>
- Yeah?<o></o>
- Yeah. We looked at how we were spending our programming time and found that about ten percent was spent on putting comments into code.<o></o>
- So, what’s wrong with that?<o></o>
- Well, at first we thought that that was a good number. And we all swapped stories about the hours we’d spent tracking down errors when people had ignored the rules and there were no comments available.<o></o>
- Tell me about it!<o></o>
- But then we took another look and it turned out that these were the exceptions, and we found that in the vast majority of cases, comments were never read again. And then we said: this is like a poker game: What are the odds that the comments we write will be important in the future? If we spend too much time on comments, then we are wasting our time. If we do too few comments, then we will pay for it down the road, because we’ll spend a bucket-load of time trying to understand what we did when something goes wrong.<o></o>
- So what did you come up with?<o></o>
- Well, we decided that the worst policy was to have a “one-size-fits-all” approach that says: “you should always write comprehensive and explicit comments”. Instead, we said to our programmers - you decide if there is a reasonable chance that someone in the future will need to see any comments at all in this procedure. If you think so, then write a comment, if not, then don’t.<o></o>
- But isn’t that dangerous? What happens if you have a programmer who can’t make that type of judgment?<o></o>
- Well then the issue is more about our hiring capability – and we don’t think that we have a problem there … we know we’ve got an intelligent team.<o></o>
- But doesn’t just about every book say that you must consistently make comments in every case? Same thing when you go on forums.<o></o>
- Well, that’s why we hope we’re onto something. Let’s hope they keep thinking that way!<o></o>

 

[Jonmo1]

The example you used to state your case actually ended up proving the case against you....

You posted some seemingly extremely simple code...

But then Norie Said...

Mind you I'd probably do it like this.

Range("A1") = 1000

Kind of cuts out the other (unneeded) 999 iterations of the loop.

You then had to explain why you wrote it that way..

... although not if the user enjoys seeing the brief flicker of sequential numbers!

Seems a bit of comment in your sopposedly simple code would have elminated that question from Norie..
I noticed the same thing immediately as well.

I know it was just meant as an example, but there it is.

Just because the purpose of the code is simple and clear to you, doesn't mean it will be simple and clear to someone else.

In a proffessional environment, who knows when someone else will need to use/see the code.


Most programmers perfer to build habbits of doing things a certain way.
When you take shortcuts, you increase your chances of forgetting the correct way later on when it counts.
Not necessarily forgetting how to do it the right way, but just simply forgetting to do it.


It is far better to have and not need, then it is to need and not have.


And seriously, do you honestly believe 10% of the time is spent writing the comments and dimming variables?
I don't think so.
I'll spend more time on a coffee break than doing those little things.

 

[MARK858]

Why are you so concerned about the programmers typing time? I was always told that you declared variables to save system resources and to make the code more efficient/faster for the end users (please note the use of s at the end of users).
Or are you also proposing not using
Application.DisplayAlerts = False
Application.ScreenUpdating = False
Application.Calculation = xlCalculationManual
to save the programmers typing time as the program will run without them.

On the subject of comments I use them to tell me what may need altering at a later date either by myself or by others, as a memory jog or to inform others who might have less knowledge what a line does(i.e. on a forum).
I have never seen anyone say you should comment everything.

I would definitely put a comment in if I used a title for a macro like

Sub Rectangle1_Click()

when the code had nothing to do with rectangles as I wouldn't have a clue what the code done 6 months later and would have to read the entire code again.

 

[martindwilson]

anything that works suits me!

 

[xlHammer]

It's actually number 3 of the Excel Commandments;

1. All pie charts are evil
2. Cell merging is for morons
3. The wisdom of variable declaration and code commenting is inviolable

 

[RoryA]

The better coding approach is to decide what approach is required for each specific situation.

Was this meant to be a rhetorical question?

At the end of the day, for a trivial example such as what you posted, no it doesn't really make sense to add comments explaining what it does, or using meaningful variable names for simple loop counters (many of us don't do that anyway).
On the other hand, a single comment explaining why the code is doing what it does, would be extremely helpful. If I came across that code in 6 months, my first thought would be "why is it doing that"?

I don't actually comment my code much (except sometimes as explanation if posting on a forum) but I do try to have a general comment as to its purpose. I figure anything beyond that won't be kept up to date, and if it's not clear what a routine is doing, it probably needs to be broken up or simplified anyway.

I don't really accept the Option Explicit argument. If you don't have it as the default, then you have to remember to type it in when needed. Much simpler to have it default, then comment out temporarily if required. Of course, following your paradigm, I'd have to have separate modules for complicated routines and easy ones, rather than simply grouping by purpose. I'd also have to waste time deciding whether a piece of code fell on the complicated side of the line or not.

Anyway, if we were really worried about efficiency and hours spent, we wouldn't be here, now would we?

 

[SydneyGeek]

I'd apply the 6 month rule. If it's not clear immediately what you did when you come back to it, it should have been commented.

I always use Option Explicit
For quick and dirty, use-and-dispose code, I don't comment.
For everything else I write a simple explanation at the top of the routine, and other comments as required. If I am about to write something big I 'wireframe' it wth comments, then write the code to match those comments.

Denis