[split] Lines of Code

[SMcNeill]

I think there is a legitimate positive challenge to reduce the lines of code. I think of it as boiling down a code's essence. It is NOT some useless exercise even if it gets silly except silly with colons of course

I used to think similar, but then I grew up. 

Well, maybe not grew up, as much as "grew lazy".

It's a lot more work to try and choose everything the most efficient to reduce lines of code.  You have to know every keyword.  Know how to tweak them and how to abuse them.  You have to come up with obscure and inane ways to generate logic.  You could simply *write* a program in 2 minutes, compile it, and have it done and running... OR, you can go back over each and every line you wrote, wrack your brain and say, "Gosh, can I reduce this to lower my line count?"

It's extra work with no payoff and it often harms readability and maintainability

IF x = 1 THEN 'someone has pressed the keyboard for input
   'do key stuff
ELSEIF x = 2 THEN 'someone has moved the mouse for input
  'do mouse stuff
ELSEIF x = 3 THEN 'it's game stick input
  'do game pad input
ELSE 'handle other undefined input (perhaps from a pen)
  'do exception stuff
END IF

Now, the above is rather readable, with comments spaced to help display thoughts and ideas as to what's going on with the code.

BUUUTTTTT...  It's so gosh darn many lines of code!  Let's reduce it!

ON x GOTO 1, 2, 3, 4

Well gosh, that's a lot less lines of code!

Except...

It's now no longer readable, and once it's translated into the C source to be compiled, it's *the exact same code*.  You reduced and mangled the BAS source to make it less user-friendly, and actually did nothing to reduce the output, flow, efficiency, or user experience for your code.

That's where my concept of "working backwards" comes into play.  It's creating code that is 0% better, and is only more complex in the end.  That shouldn't be the goal of programming.  Programming should be all about .. dum dum de dumm (drumroll)... simply getting the job done in the easiest and most efficient manner possible, that is future sustainable.

---

With QB64, it's a moot exercise in futility to worry about line count.

Code: (Select All)

IF x = 1 THEN 
   foo
ELSE
   floop
END IF

The code above translates EXACTLY the same as:

Code: (Select All)

IF x = 1 THEN foo ELSE floop

You may have reduced the white space and natural flow of your program for some sort of arbitrary line count (Gosh!  Look how good a programmer I am!  I can do in one line what someone else used FIVE lines to do!), but it changes *nothing*.  Both are translated 100% the same, but both aren't guaranteed to have the same level of human readability and understanding.

THEN you have to add in the gcc compiler and the switches you set...  It also takes that code that we write and translates it for us from C to assembly/machine code.  The level of optimization you set can really affect how it rearranges things, rendering even more of your changes moot and utterly pointless.  Your hundred lines of code might be condensed by the compiler to one single assembly instruction... OR, it might be unraveled and become 1000 lines of assembly.  

At the end of the day, the goal post should be as simple as:
1) Does the program work?
2) Does it perform adequately on your hardware for you?  
3) Is the source human readable, commented and understandable, and maintainable?

That's all one really needs to be concerned with.  Trying to break your brain to reduce down to the minimum line count is just an exercise in frustration with no real benefit.

Take the code posted in this topic as a lovely example.  Which is the better code?

Code: (Select All)

Do

    Input "Give me a value =>"; value#

    Print Using "###.## inches = ######.## millimeters"; value#, value# * 25.4

    Print Using "######.## millimeters = ###.## inches"; value#, value# / 25.4

Loop Until value# = 0

OR the last code which I posted which can run on a single line with no colons necessary:

Code: (Select All)

Print _IIf(Shell("@echo off & set /P input=Please enter a value with positive for inch and negative for millimeter: & echo|set /p=%input%|clip") <> 0 Or Val(_Clipboard$)<0, str$(Val(_Clipboard$) / -25.4)+" inches", str$(Val(_Clipboard$) * 25.4) + " millimeters")

If I was paying an employee to write this code for me, I'd accept the first code with no issues.  The second set, I'd just stare at the genius who came up with it and then tell them go back and redo it.  It's insane, hard to understand, and would be a pain in the ass to add to some existing codebase and expect some intern to be able to work with it 10 years from now.

The older I get, the less I care about line count and other such things.  Why get conceited and say, "Gosh, this is so simple, I could do it in half the lines?!"  Who cares??!  Half the lines or twice the lines, as long as it runs and does the job at the end of the day, and can be maintained in the future -- that's all that really matters.