Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Curious if I am thinking about this right.
#24
Hello!

This is a slippery and a potentially controversial question you've asked old timers. Be ready for the lectures, and heated opinions Smile

BEGIN OPINION:

Less lines does not = more readable code, IMO. There is a balance between terseness and verbosity which you can discover when you think about what you are writing from a compassionate lens with consideration of not only yourself, your future self, but also someone coming behind you and working on the same code you wrote. From this perspective, you have to consider your audience.

While a ternary statement like _IIF is fantastic brevity and a great thing once you have command of a language, if you are learning I would avoid it for all but the simplest of cases.

What are some of those? Things like checking if the number of things is more than 1 to add a plural version of a quantity.

Why do I suggest this?

Because you increase the cognitive load on yourself by making things harder to parse visually. Since you brain is a computer, it needs to be working in the space of a mental compiler.

Code: (Select All)

' Trivial example where _IIF is more readable than IF...THEN...ELSE IMO

DIM fruit as STRING
DIM num_fruits AS _UNSIGNED _BYTE

thing$ = "apple"

' First we have 1 apple so don't pluralize with "appleS"
num_fruits~%% = 1
fruit$ = _IIF(num_fruits~%% > 1, thing$ + "s", thing$)
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; fruit$; "."

' Second we have more than 1 apple so pluralize with "appleS"
num_fruits~%% = 2
fruit$ = _IIF(num_fruits~%% > 1, thing$ + "s", thing$)
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; fruit$; "."

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

' Same code with IF...THEN...ELSE

num_fruits~%% = 1
IF num_fruits~%% > 1 THEN
    fruit$ = thing$ + "s"
ELSE
    fruit$ = thing$
END IF
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; fruit$; "."

num_fruits~%% = 2
IF num_fruits~%% > 1 THEN
    fruit$ = thing$ + "s"
ELSE
    fruit$ = thing$
END IF
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; fruit$; "."


While a bit contrived, this example is perfect for _IIF.

If you have to nest more than 2 statements in a ternary, you might be better off with full on IF statements.

Be kind to your current self, your future self, and those who will come behind you.

---8<---

One more suggestion.

I do not recommend ONLY using the sigils for your types (%,$,#,!) and instead use both the full word style DIM statements AND the sigils.

Why?

Because when you are learning you need to constantly reinforce as you go what a type is. In QB64 There are many more types than in QBasic or QB45, etc. Therefore if you fall into a habit of ONLY using sigils (while not wrong and will work fine), you are not reinforcing what those sigils mean by creating the connection in your code to reinforce that meaning over and over and over.

Once you get the hang of it, then you can do whichever you like. There is no WRONG way to do it. However, I find myself always using this style still, and it's served me well. The initial burden of types and the ambiguous freedom presented about them --- to sigil or not to sigil --- to DIM or not to DIM, was much easier to come to grips with when I added my own rules and style. There is no official style.

Some may say the IDE formatting is the official style of QB64, but I dislike this style. I prefer keywords in UPPERCASE (which fucks up my brain in other languages for sure as for example in python that makes a constant, etc.) I initially was fearful of creating bad habits writing QB64 vs. these other types of modern languages, but I was pleasantly surprised to find that my brain-compiler and my language-specific thingies in my thought processes was not impacted. In fact, I found that I started preferring more strongly typed ways of working, e.g. explicit declarations vs. implicit assumptions.

---8<---

Another thing that will help you write better code is using the OPTION _EXPLICIT stuff:

Code: (Select All)

' Put this at the top of your code and brace for impact Wink
OPTION _EXPLICIT
OPTION _EXPLICITARRAY

Wiki documentation:
- OPTION _EXPLICIT
- OPTION _EXPLICITARRAY

Given my code above, it found that I didn't DIM thing$:

Code: (Select All)
Beginning C++ output from QB64 code...
[...............                                   ] 30%
Variable 'thing' (STRING) not defined
Caused by (or after):THING$ = "apple",5
LINE 9:thing$ = "apple"

Even with this small example, i've broken my own rules Smile This is why that reinforced style of DIMs and sigils is helpful for me.

---8<---

If you find yourself repeating the same code and only variables changing, that's a great candidate for a SUB or FUNCTION.

Same code as above wrapped in FUNCTIION plural:

Code: (Select All)

' Same code with function to simplify

' First we have 1 apple so don't pluralize with "appleS"
num_fruits~%% = 1
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; plural$(thing$, num_fruits~%%); "."

' Second we have more than 1 apple so pluralize with "appleS"
num_fruits~%% = 2
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; plural$(thing$, num_fruits~%%); "."

''
' Function to simplify pluralization of a thing
' @param STRING the thing to pluralize
' @param _UNSIGNED _BYTE num_things the number of things
' @return STRING the thing with an "s" appended if num_things > 1
'
FUNCTION plural$(thing$, num_things~%%)
plural$ = _IIF(num_things~%% > 1, thing$ + "s", thing$)
END FUNCTION

For the FUNCTION I document the function explicitly (because I've done this in other languages) using a weird PHP-Doc like syntax in a docblock above it.
In a strongly typed source, this is redundant. It's pretty obvious what things are, so some may say this is over-documented. Again, I do this ritualistically even if it is so, because it reinforces again the linkage in my brain compiler between the sigils and the word types.

It is perfectly legal to use this instead:
Code: (Select All)

FUNCTION plural$(thing AS STRING, num_things AS _UNSIGNED _BYTE)
plural$ = _IIF(num_things~%% > 1, thing$ + "s", thing$)
END FUNCTION

But I find that to be more cognitive load than the other way. You can fit more on a line in a function signature this way.

Again, this is one of those things that was "find out the hard way" for me.

WHATEVER YOU DO BE CONSISTENT! Find your comfort zone, and stick to it.

Hope this helps!

P.S. One more BASIC specific thing that helps my inner OCD love my various selves and others:

Do not forget you can use the line continuation character to wrap lines and adhere to maximum column widths!

Code: (Select All)
_

[Image: 8hvaVja.png]

Same code in 80 columns or less:
Code: (Select All)

' First we have 1 apple so don't pluralize with "appleS"
num_fruits~%% = 1
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; _
plural$(thing$, num_fruits~%%); "."

' Second we have more than 1 apple so pluralize with "appleS"
num_fruits~%% = 2
PRINT "I have "; _TOSTR$(num_fruits~%%); " "; _
plural$(thing$, num_fruits~%%); "."

[Image: NSbqtPc.png]
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply


Messages In This Thread
RE: Curious if I am thinking about this right. - by grymmjack - 01-20-2025, 01:42 PM



Users browsing this thread: 1 Guest(s)