2048 Puzzle

[SMcNeill]

You got me swearing...

but Steve wouild say that was the intentional message, no he wont now that I said it for him

That was the intentional message. 

Look at your code in reply #20 (https://qb64phoenix.com/forum/showthread...&pid=29316) -- there's very few lines which aren't multiple statements tossed onto a single line, just to claim that it's a low LOC count.  When you start cramming 2 to 10 lines of code on a single line, there's no longer any use in trying to use LOC as a indiciation of the code's "worthiness".

Let me take a second to point out some ugly programming, which has been crammed together to produce one line of code:

Code: (Select All)

10 Do: k$ = InKey$: _Limit 30: Loop Until k$ <> "" '                         == wait for key ==

Now, that's 4 lines of code and a label all crammed together just to say, "SEE, my line count is low!"  /BLARF!!

Let's translate this to something which is much better.  Are you ready?

Code: (Select All)

k$ = Input$(1)

Now, doing something like this, would be a valid exercise in reducing lines of code, to me.  You've taken multiple keywords and simplified them down to one simple processs. 

And yet, by cramming all the crap together on one line, it invalidates the change there.  The orginal was one line of code.  The change is one line of code.  By simply using line of code as a metric to judge the code, there's no difference in the two methods of coding.

Now regarding LOC, it seems to me, intuitively, there is a usefulness in this practice of reducing code to essentials. Maybe I am wrong. Steve is very good at it one of the reasons I respect his skills, I was hoping to see him join in with a real effort but he is busy this time of year as reported yesterday.

What is the lesson, what can I get from this little session? I am tempted to go back to my editor and forbid any line over 100 characters. I could save myself all that trouble attempting to allow an exception to 100 characters with a horizontal scroll. But it would surely be missed, even by me. But like the colon, it should be used judiciously. I even started a set of guidelines for us of colon. Opps! I called it rules, that does not work here in Basic, rules are for oneself and those who are into monologues.

To me, the lesson for line count should break down to:  *Minimal or no use of colons when counting lines of code.*

Sometimes, it makes sense to keep things together on a single line.

IF x > 2 then a = a + 1: b = b - 1: c = c / 4

^ That use makes sense to me.

Code: (Select All)

    Next: Next

Use of crap like the above is just arbitrarily cramming crap together to reduce line count.  It does nothing towards "reducing code to essentials".  It's just cramming multiple statements on one line -- and one can't even argue that it's a personal STYLE.  At least they can't when you also have this a few lines above:

Code: (Select All)

        Next
    Next

I defy anyone to say that stuff like this is "reducing code to essentials":

Code: (Select All)

If jm = 4 Then p = j * jm + ks Else If kstep = 1 Then p = j Else p = 12 + j

That's just obfuscating of code to once again arbitrarily reduce line count.  It's ugly.  It's hard to follow.  It's just a TRICK to try and manipulate the number of lines in a program, without doing anything to actually tighten up the program or improve performance.  It's not "reducing code to essentials".  It's just cramming as much crap on one line as possible, without having to scroll the screen.

---

And when it comes to " I hate horizontal scrolling! ", that's entirely dependent upon the user's monitor, IDE font size, and other factors.  The 64 LOC count of bplus's requires horizontal scrolling for me, but that's because I've been running in half screen mode with the IDE here lately, and I tend to use a large font for easiest readability with these old, tired eyes.  I don't have 120+ characters that I can display on the screen without horizontal scrolling currently.  Last I checked, my IDE has a limit of around 80 characters before horizontal scrolling occurs.

If it's going to scroll with the 64-LOC of code, then why not just cram more crap together onto a line and reduce the LOC even further?

---

Honestly, I think when using lines of code as a metric to guage a set of code, then that code should be organized in a natural and normal style of coding.

I like to see when stuff like this:

Code: (Select All)

10 Do: k$ = InKey$: _Limit 30: Loop Until k$ <> "" '                         == wait for key ==

Can be reduced down to:

Code: (Select All)

k$ = Input$(1)

This is a legitimate reduction to try and reduce a set of code down to its essentials.

Cramming crap together on the same line doesn't do that.  It's not reducing your code; it's only obfuscating it.

And -- to ME -- that's the truly UGLY code.