001-Core Programming: Why Bother to Improve Your Coding?

Dave Schwartz

Which door represents your code? Which door represents your team or your company?
Why are we in that room?
... The answer is: craftsmanship. — Uncle Bob Martin

(From the book, Clean Code, by Uncle Bob Martin.)

Uncle Bob has provided a tremendous improvement in my coding life.

Truth be told, I am not a very good programmer.
On a scale of 1 to 10, where "1" is a guy who's just written his first, "Hello World," and "10" is Bill Gates (when he was younger), I put myself at "4.5."

Sure, I do some cool stuff, and, as a designer, I'm about a "12," but my skill set is very vertical. That is, I only learn what I absolutely have to learn. Probably we have this in common.

Until the last year or so, I was completely self-taught. It was then that I had a couple of problems to solve that I just didn't know how to do and I decided that I could spend (say) 40 hours figuring out the HOW or I could pay someone to show me.

Simple business decision. 40 hours of my time vs. 1 hour of someone else's time for about $80. Since I value my time at far more than $2 per hour, it was a clown question.

"Yes, but I don't do this for a living."
No, you probably don't.
Any more than you are a professional horse player, but you still take your handicapping seriously, right?
DEADLY SERIOUS, I'd guess.

Since the effectiveness of your software is a key element in your handicapping success, the ability to write good code - AND TO DO IT QUICKLY - could positively impact your end result.

Final Thoughts
One of the coders I have great respect for told me that he watched a video a few years back where a company did screen videos of all its programmers. Then they studied them.

What they found was that most programmers spent a whopping 95% of their time looking for old code!

NINETY-FIVE... PERCENT... of their time.

When I heard that, I said, "Oh, that's crazy. Certainly not me."
Later that same day, I spent over an hour looking for code with HSH because I knew I had done it before and KNEW that it worked.

If that characterization is even remotely close to true - even if it is only 75% of the time - that means for every hour we spend, we waste THREE!

Imagine if you could learn new skills that make those things that you do not know how to do not only possible, but fun and exciting to do.

Imagine what it would do for your mind.
Your game.
Your joy of life.

I invite you to stop being a programmer and become a BAD ASS CODER.

______________________
What are your thoughts?
______________________

#CorePrg

RanchWest

An even bigger problem is to not look for the code at all, writing it again. That means it isn't tested and may not function exactly the same.

With most coding, our initial objective can be fairly well defined and the program can be designed.

With handicapping, we can easily find a BBD (bigger, better deal) and through a major shift in our thought process have major changes to our objective. Managing the code gets really difficult.

It is easy to come up with more ideas than can be implemented efficiently within time constraints. I ALWAYS have more ideas than time. And, every day I think... man, when I finish this, it will finally be caught up. Then there's another epiphany and it all starts again.

I have been writing more or less the same program for over 25 years. It is not nearly as organized as I would like after all the changes. The original program cannot easily be found within what I have today, major changes. I really need a total re-write. But when? I keep coming up with and implementing new ideas, some of which I consider great, at least in my own mind.

So, I guess my best advice, which I need to take more seriously, is to slow down and keep everything tidy and self-documented.

Dave Schwartz

As I write The Studio, I am acutely aware of the difference between my coding now and 20 years ago because I have dozens of functions to import. It is downright depressing to see my poor coding habits from the past.

However, things that have been in place for a decade or more, or something that is very complex, needs to remain as is.

Going forward, I am committed to:
Zero documentation.
Because the code is so clear and the variables named so obviously that no docs are needed.
This includes function names.
(Often called writing explicit code.

Always code to my own standards.
Standard icons, button sizes, window ratios, etc.
Every button has a tool tip, etc.

Never write the same code twice.
Turn it into a function or procedure if possible.

Code that fits on a single page
If it's going to stretch across multiple pages, then there should be functions or routines that contain the excess code.

Avoid too much Overloading
Only use the obvious

Declare all variables
Variables should not be declared via use, but rather declared as local or global variables.

Avoid Global Variables
... except when absolutely necessary.

RanchWest

You mention your standards. Your examples have to do with the output. I have strict standards in writing the code... always the same indentation, capitalization, white space, line continuation practices, variable naming conventions, etc. It makes the code much easier to read. When I was a programmer, we would have code walk-throughs and if you wrote outside the standards, you'd really get raked over the coals. That was an even tougher situation because someone else might have to read the code, but it s very important that you be able to read it yourself.

Steven

I'm self taught too but while I was learning, I never considered time to be an issue. It takes what it takes. I consequently became a major "trial and error" type programmers. I have gotten much better but I still don't think I can (or should) write undocumented code and I still have so much I need to learn.

I am trying my best at this time to try and emulate the information that Dave showed us in the KY Derby video. The closest "blueprint" that I have is the Practical Handicapping workshop (1-2-3 System) with the "other" developed PSR1 and PSR1x. If I can't get to the point where I am confident in my program I suspect that I will be one of the first buyers of the Studio and further suspect that my programming will slow way down.

RanchWest

There are ways to produce self-documenting code. For instance, if you have an array of differing values, you can self-document the elements.

If your language permits defining constants, you can do this:

#define hQUIRIN 1
#define hSPEED_RACE_1 2

local aValues := {}

// SIZE the array in your language here

aValues[hQUIRIN] := MY_FILE->QUIRIN
aValues[hSPEED_RACE_1 := MY_FILE->SPEED_1

If your language does not support defining constants (most do), use a variable with the variable type denoted in the variable name. In this case, I use "n" as the prefix for a "number" and "a" for "array".

local aValues := {}
local nE_Quirin := 1
local nE_Speed_Race_1 := 2

// SIZE the array in your language here

aValues[nE_Quirin] := MY_FILE->QUIRIN
aValues[nE_Speed_Race_1] := MY_FILE->SPEED_1

Do not reference the array like the following because it will be very difficult to read later:

aValues[1] := MY_FILE->QUIRIN
aValues[2] := MY_FILE->SPEED_1

You could end up with this unreadable code:

nMyCoolNumber := aValues[2] / aValues[1]

Instead, write it like this:

nMyCoolNumber := aValues[hSPEED_RACE_1] / aValues[hQUIRIN]

Dave Schwartz

↪RanchWest

WONDERFUL POST!

Have you been reading this book?
Clean Code: A Handbook of Agile Software Craftsmanship

RanchWest

No, I have not read that book. I will take a look later today.

RanchWest

I've looked at a bit of the book and I would like to share something that came to mind.

Programming projects are based on requirements. The better defined the requirements, the better the programmer can expect to meet those requirements. Then comes the caveat for the handicapping programmer. We are always looking for ways to improve not only our programming, but our core requirements. Maybe we should shift more toward Sartin methodology or speed or class or beatable favorites or form cycles or whatever our personal buzz word is today. Maybe we have found a better approach to Artificial Intelligence or research. It is very easy for our program to not even resemble our original program.. not just because we have a new menu system or a new way of managing windows, but because our requirements have drastically changed beyond anything we ever envisioned.

So, i think in this type of programming, we should anticipate that periodically a significant clean up will be required... regardless of how well you've cleaned up along the way. And that makes the cleanup along the way that much more important.

Steven

I am on probably my fourth or fifth version (hopefully a final version) of my software. I found that as I become more knowledgeable and better at programming, my code became less and less clunky. However in order to get to "less clunky" programming, I had to abandon hundreds of hours of code in order to write better code. I'm still not much more than a hobby programmer but I've not found anything I can't do or get done in some round about manner.

I don't get away with zero documentation/notation but I am pretty much to minimum documentation/notation.

Dave Schwartz

I am on probably my fourth or fifth version (hopefully a final version) of my software. — Steven

There is an old saying... "Being a programmer means never having to say you are finished."

I don't get away with zero documentation/notation but I am pretty much to minimum documentation/notation. I had to abandon hundreds of hours of code in order to write better code. — Steven

I feel your pain.
I had to abandon over 10,000 hours worth of working code from HSH!
(That's 2/3s of all the coding I did in of 20 years on HSH!)

I've built a strict rule:
"All new code will fit my personal 10-x Coding Standards."

I am sure you know how difficult this is - to take the CODING HIGH ROAD for everything new.

Like, I was writing a simple set of list-up/down buttons.
Imagine, you have an alpha list but you want it sorted in a LOGICAL ORDER way.
Further, you don't want the user to have to ever type in a logical order number.

In HSH, I actually used numbers, but I vowed to do better code in the Studio and going forward.

So, I bit the bullet and spent about 15 hours writing a set of functions to manage this, instead of maybe 1 hour to get it working the old way.
(If you want to know how it works, I'd be happy to show you.)

But there was a payoff.
I've now used it in about 10 different browses, and have begun to reap the returns, because it now takes about 15 minutes to facilitate adding those buttons and making them functional in any browse!

Not EVEN yet, but getting there.

RanchWest

(If you want to know how it works, I'd be happy to show you.) — Dave Schwartz

/
What language are you using, Dave?

Dave Schwartz

What language are you using, Dave? — RanchWest

I use a language called Clarion.
http://www.softvelocity.com/

RanchWest

A quick tip...

Try to keep coding on the positive.

Saying .NOT. or ! or however you language says not is usually not the clearest way to write code.

Instead of

If .NOT. eof()
// do something
endif

write

if eof()
else
// do something
endif

I think you'll come to appreciate the clarity.

Dave Schwartz

@RanchWest

So glad you popped this to the top.

How do you handle comments & documentation in your code?

RanchWest

I put comments in when I feel they are really needed, but to be honest that is often because my function names, variable names and array elements are not expressed in a self-documenting fashion.... I guess you could say mostly from laziness or rushing. I get on a roll with a new concept and I focus too much on completion and not enough on keeping things tidy. It usually leads to regret, especially when it comes to array elements.

But I do feel that complex computations do sometimes need comments to explain the objective. Or, for example, I am dealing with yards... it is nice to comment the furlongs, though those, too, could be expressed as manifest constants.

RanchWest

One thing that strikes me is that 30 years ago speed was a huge factor. I actually did some screens in assembly language because otherwise you could actually see the screen paint and that gave me grief. Today, computers are so fast that it is better to write clean code than to worry about things like variable name length and such. But, it is still sometimes important to do things one time and not keep going back and doing it over and over.

Dave Schwartz

You and I are completely on the same page.
So much of the code I wrote in HSH is truly painful to look at now. LOL

I, too, wrote assembler. My coding was not only slow but ineffective.

Funny but the group of programmers I hang with, many I've known for almost 3 decades... well, I used to think I was like a 7.5 on the scale of 1-10. Now, as I see how they've grown - especially horizontally while I remained vertical - I've changed that to a 4.5.

RanchWest

↪Dave Schwartz

,

Many things in life are humbling. Like Saratoga, lol (unless you're Jack). Or, look on my FB page at the display at the leather show. I do good leatherwork, but some of that stuff is ridiculously good... and humbling.

I don't know if you've done any object-oriented programming, but one thing that is nice is being able to store data in an object and access it. Makes it easier to make a calculation one time and be done with it, just access the calculated value.

Dave Schwartz

I don't know if you've done any object-oriented programming, but one thing that is nice is being able to store data in an object and access it. Makes it easier to make a calculation one time and be done with it, just access the calculated value. — RanchWest

I checked out of OOP almost 2 decades back. Just didn't like it.
But admittedly, I use a language whose original form of OOP was a lot like everything being a complicated way to call a function.

The biggest changes for me have been in my approach to organization.
First I wrote more functions, then added more routines.
I created a rule that said all code for anything goes on a single visible page.

As an example, here's the main page of what is called the My Handicapping section.

This is the part where your handicapping is stored so that the model and the AI can help you improve things.

Now, this is the BEFORE picture. No code has been written yet, but the comments (green) make it very clear what I'm about to write.

RanchWest

My point about OOP is that it provides a way of holding values and accessing them without recalculation. Of course, that can be done with static variables inside a function. And there are various ways of pushing, popping or accessing those stored values. The key is to not recalculate every time you need the value and I admit to being bad about doing that. But, I have been good about sharing the code that is the basic framework for many of my calculations.

The truth about 100% OOP is that it relies on perfect design and even then can become nearly impossible to maintain, especially if the basic requirements change. That doesn't mean that objects are not useful.

Dave Schwartz

My point about OOP is that it provides a way of holding values and accessing them without recalculation. Of course, that can be done with static variables inside a function. And there are various ways of pushing, popping or accessing those stored values. The key is to not recalculate every time you need the value and I admit to being bad about doing that. But, I have been good about sharing the code that is the basic framework for many of my calculations. — RanchWest

I'm not sure I understand this, but I think you're saying that you can (effectively) load a value somewhere to recall it without actually storing it in a variable.

Is it like a location?

RanchWest

A variable or an instance variable. The emphasis is on not doing calculations over and over, especially calculations that are complex enough to take up time. The variable can be static within a function and accessible through a call to the function. It's the workaround to avoid global variables.

RanchWest

function MySortaGlobal( xValue )
static xKeep

if xValue == NIL
else
xKeep := xValue
endif

return xKeep

It might be written a little differently in different languages. If you don't pass in a value, then the stored value is returned. If you do pass a value, then that value is stored. Obviously, this could be made more complex, storing multiple values etc.

Dave Schwartz

That appears to be a standard function.
That is, you pass a value (or several values) and return a value (or several values).

Thus, you prevent multiple coding of the same computation, but you still have to call the function again to get the value again.

RanchWest

Yes, but I'll give you an example. I know you calculate a strength number where you look at the speed figures for all of the lines of all of the horses in a race. If you store that number, then when you need it again you don't have to do that calculation again. You still have about the same amount of code, but the execution time is less.
t

Dave Schwartz

I don't understand what you mean by "store that number."
To me that means "put it in a global variable."

RanchWest

If your language supports static variables, then those are persistent, but not globally. So, if a function is holding that static value, then the value can be accessed as in the function I showed above. It is available globally, but is not a global variable. As you likely know, global variables are a no no.

Dave Schwartz

Ah, now I understand (I think).

What does the call to reget the variable look like?

RanchWest

If a value is passed in, that SETS the stored value. If no value is passed in, that GETS (fetches) the stored value. In my example, I denoted no passed value as being NIL, but the exact coding would depend on the language.

Dave Schwartz

I'm still confused.

Function(X1,X2,X3)
Y= X1 + X2 * X3
Return Y

So, if you pass (say) 3 values (x2,x2,x3), and it returns (Y), how do you fetch Y again without passing the values again?

001-Core Programming: Why Bother to Improve Your Coding?

Please register to see more

Categories

More Discussions