5 hours ago
Spriggsy, the post on if/then, I agree, but only if there's just a THEN, and not one or more ELSES in it.
Back a page ago B+ addressed why we have one letter variables. I did that a lot doing BASIC on a commodore 64. It can only see two chars max. I use them a lot for short temporary var needs, and have had some collide where "a" here wasn't supposed to talk to "a" over there. (Learning and using SCOPE is so helpful, do you want to just use one area for your var or all over?)
I agree with most of the "shorter is not better" comments, make it readable, understandable.
Usually a BIG program will have to be split into smaller parts and it can be like a tree, big trunk, big branches, smaller branches, then leaves.
A big job program does not need detailed code splitting hairs inside the main loop. Put that in a sub or a FN outside the main area.
Subroutines are made for splitting up the labor. You gonna load data, get a sub, call it load, gonna save? Get a sub. Only called once? Still do it in a sub. Later you'll be looking for where you save or load, made it easy to find. You'll look at the code and not see tons of details when you only need to know, this is where I save, this is where I load. Details are over there somewhere.
To make source code readable, you might be thinking about other people looking at it and using it and trying to follow it. Or you might only care about doing it yourself. You might need to see what you wrote 10 years ago and not remember any details. Then you'll wish you'd used more comments and spread out lines and made stuff you can read easier.
Well written code is an art. But maybe we all don't have time to create art either. Get it done any way you can is also understandable, but I would try to make code somewhat followable while doing it.
hrug:
Jack
Back a page ago B+ addressed why we have one letter variables. I did that a lot doing BASIC on a commodore 64. It can only see two chars max. I use them a lot for short temporary var needs, and have had some collide where "a" here wasn't supposed to talk to "a" over there. (Learning and using SCOPE is so helpful, do you want to just use one area for your var or all over?)
I agree with most of the "shorter is not better" comments, make it readable, understandable.
Usually a BIG program will have to be split into smaller parts and it can be like a tree, big trunk, big branches, smaller branches, then leaves.
A big job program does not need detailed code splitting hairs inside the main loop. Put that in a sub or a FN outside the main area.
Subroutines are made for splitting up the labor. You gonna load data, get a sub, call it load, gonna save? Get a sub. Only called once? Still do it in a sub. Later you'll be looking for where you save or load, made it easy to find. You'll look at the code and not see tons of details when you only need to know, this is where I save, this is where I load. Details are over there somewhere.
To make source code readable, you might be thinking about other people looking at it and using it and trying to follow it. Or you might only care about doing it yourself. You might need to see what you wrote 10 years ago and not remember any details. Then you'll wish you'd used more comments and spread out lines and made stuff you can read easier.
Well written code is an art. But maybe we all don't have time to create art either. Get it done any way you can is also understandable, but I would try to make code somewhat followable while doing it.
hrug: Jack
MoreCowbell(everything)