[split] Lines of Code

[bplus]

"Less lines does not = more readable code"

agreed! 100% but this does not mean less readable either. Fact is readable is an opinion and that is based on ones personal experiences.
(BTW "Less lines <> readable code" less words but don't use it in an English paper )

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

In reducing lines of code here, what step had I taken that wasn't instructive to a beginner?
Never did I say well you can put it all one one line by using colons because that is not helpful in learning; thats what a bot would do, nothing to learn there. Seems the use _IIF was a popular outcome of this thread. I think _InputBox$ dialog has some great advantages over the simpler Input. How many newbies know about multiple assignments from one Input prompt?

The final one-liner here is less than appealing because it exceeds a certain tolerable line width. line extensions? eeeeh only if you must! better than having to use a horizontal scroller. Thats when I consider shortening variable names or strings.

Tell me, you look at a text book that is 1000 pages and you look at a summary statement one line long, which are you more inclined to read?
Maybe the one-liner will help motivate you to read the text book.

[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. 

[Pete]

I think by the time I reach 80, my "Hello World!" program will be rewritten to include the same one line of working code, but I'll need to add at least 20 remark lines. I'm so thankful, going forward, for bulk remark in QB64. I'll need it!

My thoughts are that shortening code is a lot of fun, but not necessary. I look at it as a brain exercise. Of course, if I over do it, then I have to put up with that pain of injecting GatorAid into my cerebrum. Hey, that really stings sometimes!

Also, since QB64 is a translator, we all need to keep in mind that no matter how hard we work to shorten our source code, the compiled executable will be larger than the same program written in a native language like FreakBasic. So some people will still bitch that the code is too big!

I'm camping with Steve on this one.

Pete

[grymmjack]

"Less lines does not = more readable code"

agreed! 100% but this does not mean less readable either. Fact is readable is an opinion and that is based on ones personal experiences.
(BTW "Less lines <> readable code" less words but don't use it in an English paper )

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

In reducing lines of code here, what step had I taken that wasn't instructive to a beginner?
Never did I say well you can put it all one one line by using colons because that is not helpful in learning; thats what a bot would do, nothing to learn there. Seems the use _IIF was a popular outcome of this thread. I think _InputBox$ dialog has some great advantages over the simpler Input. How many newbies know about multiple assignments from  one Input prompt?

The final one-liner here is less than appealing because it exceeds a certain tolerable line width. line extensions? eeeeh only if you must! better than having to use a horizontal scroller. Thats when I consider shortening variable names or strings.

Tell me, you look at a text book that is 1000 pages and you look at a summary statement one line long, which are you more inclined to read?
Maybe the one-liner will help motivate you to read the text book.

Hey @bplus was not knocking anything you wrote specifically.

He asked an open-ended question and shared my own tips to him. That's it

The idea of less code = better code, not always true. DEFINITELY prefer readability over less LOC IMO.

Your code is great, readable, etc. Aside from the sea of single letter variables you use (lol not a shot at you; you are a master/guru).

This advice I'm giving isn't for you master Yoda, it's for little boy Luke

You also raise a good point. I think a good lesson to experience for oneself is what they prefer and stick to it.

It usually makes very little difference to the program being compiled how we got there

[bplus]

Oh man! I did not see the 10:09 PM EDIT of Steve's crazy long one-liner employing some interesting tools!
+1 It's ugly long but I like it!
I can't imagine a coder who doesn't find this stuff interesting.

Who cares what the code looks like as long as it does it's job?

Maybe those who think code writing could be an art.

[bplus]

Ah @Pete yes I can see a day coming when someone writes a book of how they came to write the line:
Print "Hello World!"

The book will hopefully be more interesting than the line.

Wait... no it will be a You Toobe thing.

" I look at it as a brain exercise." 100% Right!!!

---

GJ: "Hey @bplus was not knocking anything you wrote specifically."

The single letter things arise around a style or convention. i, x, y, dx, dy, mx, my, mb or mb1 if there is an mb2 s$ for string, n or num for integer usually or any number not scientically noted... which need explanation?

I do get a feeling of defensiveness. But OK forums are about sharing ideas, good.

It means we are alive and thinking!

[SMcNeill]

Oh man! I did not see the 10:09 PM EDIT of Steve's crazy long one-liner employing some interesting tools!
+1 It's ugly long but I like it!
I can't imagine a coder who doesn't find this stuff interesting.

Who cares what the code looks like as long as it does it's job?

Maybe those who think code writing could be an art.

It's not really the type of code that people should be studying for any sort of 'real world application' though.  It's good for a thought experiment, and a 'is it possible' type thing, but absolute nuts in a "Should I use this method" perspective.  Like I mentioned -- it's twisting the commands with "obscure and inane ways to generate logic".

One line which...

Shells to the console.
passes a batch command -- a very ugly, multiline batch command joined by & linkers which are the equivalent of colons in BASIC
that batch command makes a variable
asked the user to input a value into that variable
returns the value to the clipboard for later use
returns to the program
Which then checks to make certain a value was given and if that clipboard value was less than 0 or not.
If the value is less than 0, the _IIF will return the inches conversion from the clipboard value copied
If the value is not less than 0, the )IIF will return the negative millimeters conversion from the clipboard value copied.

.
.
.

It's a completely insane way to do things.

Does it generate the shortest line count and user input? Sure, it does!

Is it something that should ever actually be done in programming? Nope! It's crazy and prone to break on a zillion points in the future, if the OS changes the Terminal or the Console, or if the user is stuff with the clipboard, or a zillion other things that could screw up that interaction.

It's a good thought exercise, and *technically* it works. Practically though, it's not the type of thing that one would ever see or use outside of thought exercises.

---

A similar example would be in engineering: Ask any engineer how to make a 1970 Volkswagon go 200 miles per hour without some form of rocket or major alteration done to the vehicle.

One smart arse is going to speak up and say, "Push it off the top of the Grand Canyon and set the radar gun before it hits the ground."

*Technically*, they'd be right and it'd be a working solution. Practically however, it's not something that you'd ever really want to implement for any real use case in the real world.

---

It's good for trying to think outside of the box and pushing what CAN be done, or trying to just challenge one's perspective on things. I just don't think it's something that one needs to push so heavily on someone just starting the language and on Lesson Two of the tutorial.

One doesn't talk advanced philosophy in a classroom where the students are just learning to speak the language.

And that's not to say that it's wrong to speak philosophy. It's just one should think about the time and place, and perhaps move such in depth and complex subjects somewhere a little more refined so as to not discourage the newcomers as they struggle with the basics.

---

I do get a feeling of defensiveness.

Apologies, if you feel like I'm attacking you or anything. That's not my intent at all.

Personally, I *like* the mental thought challenge of trying to reduce the number of lines in a set of code. It's something that I feel more of the *advanced* coders should do from time to time, as it encourages one to look at the tools in their programming set and see if they're the proper ones for the job, or if they can be used more efficiently.

My only concern is with someone picking up the language thinking that it's okay to write such junk as I did, just to keep line count down. Beginners should focus on simply *writing code that works*, first and foremost. Once they've learned the different keywords, and learned how to put them together and make things flow and work properly, THEN they can start to think about things like, "Would DO be better here, or FOR? Can I rearrange this logic to improve performance? Can I shorten this workflow to something simpler?"

Thing is, they have to know how to make it work first, before bothering to worry about how to make it work with the least amount of code.

And that's why I want to stress that obsession over lines of code isn't something that most folks need to worry about. It's not that I'm speaking to YOU in particular; you've mastered the language enough to appreciate the nuances and enjoy looking at the obscure and unusual ways to do things. I just don't want everyone else (particularly those just learning the language) to think that it's something which THEY have to obsess over, or a standard that they should strive to live up to.

A lot of times, it's a lot like those guys who go out and beat golf-ball sized dents all in their sexy little corvette -- it makes it more aerodynamic and gives 2 extra mph to the top speed!! Does it work? Sure!! But does it make it look like crap and lower the resell value for anyone else in the world....

[bplus]

Yeah I did not mean for Less LOC as a way of coding all the time, sheesh one look at my code over the years would tell otherwise If that was the impression I was making then good that that should be pointed out. Its about developing the alternate ways to do things, when one path is blocked a work around is very likely possible but you have to break out of your habits maybe even your style, get ugly once and awhile sometimes it's interesting as heck!

[grymmjack]

Ah @Pete yes I can see a day coming when someone writes a book of how they came to write the line:
Print "Hello World!"

The book will hopefully be more interesting than the line.

Wait... no it will be a You Toobe thing.

" I look at it as a brain exercise." 100% Right!!!

---

GJ: "Hey @bplus was not knocking anything you wrote specifically."

The single letter things arise around a style or convention. i, x, y, dx, dy, mx, my, mb or mb1 if there is an mb2 s$ for string, n or num for integer usually or any number not scientically noted... which need explanation?

I do get a feeling of defensiveness. But OK forums are about sharing ideas, good.

It means we are alive and thinking!

Re: single letter vars - none, that was a joke. I was kidding

Completely understandable @bplus

[bplus]

I do know where the sea of single letters comes from, old QBx code or even older GW.

Back in the day when every byte mattered! It's very hard reading!

It's true in my code too, sometimes I am just going after an effect, doesn't matter what the code looks like. I just want to see my vision up on the screen working.

In fact the first rule as Steve mentioned before is to just get the code to work.

Then worry about all the other stuff for showing off, speed, readability, flexibility, brevity ie effectiveness (I do seem to have the 2 equated), oh elegance my favorite!

OH BTW it's hell changing one letter variables to more descriptive names after you get the code working.