[split] Lines of Code

[SpriggsySpriggs]

I ain't reading everything in this thread but my two cents is that LOC is the Least Of my Concerns. Get the product working and get it working well. Who gives a shit how long the source is.

[Pete]

Yep, go to China Town and ask for Who.... because Who gives a shit!

Oh and Steve. The only way you get a Volkswagen Bug up to 200 is to blow it the **** up. It's fun to watch, and you also get credit for performing a valuable public service.

Pete

- Deport Now. Ask Me How!

[mdijkens]

When a bit older, I really want to be able to understand my code from a couple of years ago

Sometimes I intentionally put all statements on separate lines to show all separate steps that are done and give them a bit more 'weight' in the sub or function:

Code: (Select All)

if order% = _TRUE then

  Input "What do you want to order? ", food$

Else

  Print "Goodbye"

End If

Sometimes I put statements on the same line to show they belong together and do some small housekeeping:

Code: (Select All)

if groupsize% < 10 then groupsize% = groupsize% + 1 Else groups% = groups% + 1: groupsize% = 0

[SMcNeill]

Code: (Select All)

groupsize = groupsize + 1   'Increase the size of the group by 1
groups = groups + groupsize \ 10  'the there's 10 or more, break them into new groups
groupsize = groupsuze mod 10 'the groupsize of the empty group is now the leftovers

And ^ there's an example where multiple lines are better than that single line of code.  No if to deal with, so no decision making or comparison involved.  Just basic one step maths, with room beside each statement to remark what it's doing and explain the thought process behind it.  It's going to me more efficient than the single line statement, and it even works if large additions were to suddenly pop up such as 23 new people getting off a bus all at once, making it more flexible and easy to expand if the code usage needs an upgrade in the future.

It's more lines of code, but it's BETTER code in many ways, and that's the point I've been trying to make all along.  Few lines of code seldom makes more efficient or better programs.  It just makes more work. 

[mdijkens]

Your code is more efficient and better in what it does.

Still (fully depending on functional view of the code at that place) I would put them on 1 line if managing groups & groupsizes is not the main focus of the function it is in; it might be some less important housekeeping.
Then I would prefer to only occupy one line on my screen

If this was in a function with the main responsibility of managing groups & groupsizes, I would put them on 3 separate lines

[SpriggsySpriggs]

Minimizing lines is good in only a couple of ways, for me:

Code: (Select All)

Dim As Long a: a = 5

You don't need two lines for that. The above crudely emulates how other languages allow you to assign a value during the definition.

Code: (Select All)

If thing = 1 Then DoThing()

Rather than:

Code: (Select All)

If thing = 1 Then
DoThing()
End If

[Pete]

I'm with Spriggsy on the use of IF/THEN blocks. I use them if multiple statements are part of the condition, not just a single statement. I also look at the statement(s) length on the line. Frankly, I'd rather be able to read everything without lateral scrolling. Any good chiropractor will tell you doing it that way is better than developing a bad case of SCROLLIOSIS.

Wait... Ah, Steve. Who was it you asked me to pun to death, yesterday?

Pete

[Jack002]

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