Which Is Better Coding?

[peterpre]

Which is better coding - A) or B)?


A)
Sub Rectangle1_Click()
For x = 1 To 1000
Range("A1") = x
Next
End Sub

B)
Option Explicit
Sub Rectangle1_Click()

'Procedure to do a count up to 1000 and to show the value in cell A1
'Original version: October 29 2011; Author: PeterCar

Dim iLoop As Integer
Dim iMax_Count As Integer

iMax_Count = 1000

For iLoop = 1 To iMax_Count
Range("A1") = iLoop
Next

End Sub

I would say that A) is better, because B) is lazy.

 

[Norie]

Eh, surely you mean B) is better and A) is lazy?

 

[peterpre]

Eh, surely you mean B) is better and A) is lazy?

No - I mean A is better.

If the task to be done is really simple, then it is inefficient to type extra code.

The "conventional wisdom" is to say something like "You should always use "Options Explicit" and have a systematic naming convention".

However, in simple macros, such as the one above, it is actually easier for subsequent users to read A) rather than B), and, as I say, B) requires extra typing - a waste of time.

Now the response might be "I like to keep to a disciplined approach in all cases". But this is lazy. The skill is to determine when a macro is simple enough to not require "accepted best practices". Of couse, I gave a very simple example . But there is definitely a line that needs to be determined.

As I say, the lazy intellectual approach is to always "stick to the rules". The better coding approach is to decide what approach is required for each specific situation.

 

[Norie]

If it was something as simple as the example, or a one-off, perhaps it would be OK to use A).

Really don't think so for something more complicated that might be used and viewed by others after you long gone.

Mind you I'd probably do it like this.

Range("A1") = 1000

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

 

[peterpre]

If it was something as simple as the example, or a one-off, perhaps it would be OK to use A).

Really don't think so for something more complicated that might be used and viewed by others after you long gone.

Mind you I'd probably do it like this.

Range("A1") = 1000

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

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

But it is a serious question - I think there is an awful lot of hours wasted across the world every day by people "over engineering" and "over commenting" code. There needs to be a balance, not a "one size fits all" orthodoxy.

 

[Norie]

All you need to do to add Option Explicit to each module is goto Tools>Options...

There's also tools out there, eg MZ-Tools, that will automatically create code stubs for you which include the type of header info you included in B).

A lot of people will argue, including myself, that taking the time to do the sort of thing in B) actually saves time in the long run.

The code's easier to debug, easier to understand and follow, easier to alter, easier to re-use etc.

Anyway, I don't think there is a 'one size fits all' orthodoxy - a lot of coding styles are down to personal choice.

 

[peterpre]

All you need to do to add Option Explicit to each module is goto Tools>Options...

There's also tools out there, eg MZ-Tools, that will automatically create code stubs for you which include the type of header info you included in B).

A lot of people will argue, including myself, that taking the time to do the sort of thing in B) actually saves time in the long run.

The code's easier to debug, easier to understand and follow, easier to alter, easier to re-use etc.

Anyway, I don't think there is a 'one size fits all' orthodoxy - a lot of coding styles are down to personal choice.

I agree about Option Explicit, and that there are good tools out there.

By "one size fits all" I mean, for example the idea that "you should always use a systematic naming convention", and was not referring to any particular naming convention.

I think the issue is essentially an optimization problem. Let's think about the US as whole. We probably have about, say, 1 billion hours per year being spent by the various programmers creating code - a significant investment of time.

So how do we minimize the total time spent to achieve the necessary output - which is working programs.

If all code, whether simple or complex, was undocumented and used uninformative variable names, then the hours spent creating the code would be lower, but the hours spent updating or correcting that code would be higher - because people would be spending ages trying to understand what the code is doing.

Conversely,... well, you get it.

So the question is: have we got the right balance?

I am saying we have gone too far in one direction, whereas, I think you are saying we currently have it right.

Difficult issues - but it really does deal with thousands of hours of people's time,

 

[Norie]

A) Slightly quicker to write, lot longer to fix.

B) Slightly longer to write, lot quicker to fix

 

[peterpre]

A) Slightly quicker to write, lot longer to fix.

B) Slightly longer to write, lot quicker to fix

For Simple Requirements:
A) Quicker to write, same time or slightly quicker to fix
B) Longer to write, same time or slightly slower to fix

For Complex Requirements:
A) Quicker to write, longer to fix
B) Longer to write, quicker to fix

So question is: where is the line between simple and complex?

 

[peterpre]

... and now I think about it, when you say

"All you need to do to add Option Explicit to each module is goto Tools>Options"

... making Option Explicit a default is a pefect example of orthodoxy. Once you turn this on as the default, then anywhere in your code, even for a simple thing, you are forced to declare your variable.

There must be thousands of hours per year wasted in the world because of this setting alone!