Author Topic: QB64 REPORT S02E05: Coding Styles  (Read 1569 times)

0 Members and 1 Guest are viewing this topic.

Online FellippeHeitor

  • QB64 Developer
  • Forum Resident
  • Posts: 2701
  • LET IT = BE
    • QB64.org
QB64 REPORT S02E05: Coding Styles
« on: November 30, 2020, 12:41:20 AM »
@STxAxTIC, @SpriggsySpriggs, @Cobalt and I share our coding styles and discuss how much it matters to make your code readable - and not just compilable.


Offline Dav

  • Seasoned Forum Regular
  • Posts: 498
Re: QB64 REPORT S02E05: Coding Styles
« Reply #1 on: November 30, 2020, 08:32:10 AM »
Cool%, AnotherInteresting QB64_REPORT epi.sode.

I enjoyed listening to this over breakfast this morning. 

Thanks.

- Dav


Online FellippeHeitor

  • QB64 Developer
  • Forum Resident
  • Posts: 2701
  • LET IT = BE
    • QB64.org
Re: QB64 REPORT S02E05: Coding Styles
« Reply #2 on: November 30, 2020, 08:56:33 AM »
Cool%, AnotherInteresting QB64_REPORT epi.sode.

I enjoyed listening to this over breakfast this morning. 

Thanks.

- Dav


LOL, love the variables!

Glad you enjoyed it! You're invited to join us next time too, man. I know you're familiar with microphones.

Offline MasterGy

  • Forum Regular
  • Posts: 125
  • people lie, math never lies
Re: QB64 REPORT S02E05: Coding Styles
« Reply #3 on: November 30, 2020, 11:30:30 AM »
They talked about something interesting.
It has never turned my mind yet to be different to evaluate. I do it for myself, it’s really more transparent to me. Everything is on one screen, and if you believe it or not, I know exactly what it means when I look at it like this: “nex = ABS (sx = 0 OR sx = maze_x - 1) * -1 * SGN (sx)” I could have described this more in line with IFs as well, but why would it have been better? The mistake is that if I had to change something later, it would be a problem for me to understand.
But I respect your opinions!
I tried to find an explanation for this phenomenon. I never expected this to be a topic of debate. Maybe the language. I read somewhere that not someone will be able to write a good program because of how well they understand math, but because of how good their language is. I didn't deal with a foreign language, I know a little English, but I write this letter orally and then translate it with google translate.
Excessive compression may come from the Hungarian language, where up to 50 meanings can be created with 1 basic word and rag, sign, suffix, suffix. for example, “megszentségteleníthetetlenségeskedéseitekért”. Understanding this can be described in English in several sentences, full of the term “IF”.
Adding a rag, sign, suffix is ​​universal to any word. I'm sorry, I was just trying to make some kind of excuse, an explanation. Maybe I'm wrong, I'm sorry.
I wrote a short little program that replaces ":" with "enter" in an ascii file, and will I be nicer? :)

Online Pete

  • Forum Resident
  • Posts: 2361
  • Cuz I sez so, varmint!
Re: QB64 REPORT S02E05: Coding Styles
« Reply #4 on: November 30, 2020, 11:51:33 AM »
You totally left out the discussion on coding in all caps, no remarks, no indentation, and no spacing between lines! You guys would have loved me, even more, back in the 1990's.

PETE

Online SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3206
    • Steve’s QB64 Archive Forum
Re: QB64 REPORT S02E05: Coding Styles
« Reply #5 on: November 30, 2020, 01:12:58 PM »
@MasterGy — The important thing is to code in a style which is decipherable for the user base of that code.  It’s why many companies have such long, drawn out rulesets for how to properly code a program.  As long as you’re coding for yourself, code in the style that makes the most sense to you.  If you’re coding a library, or such, for other people to be able to use, or modify, in the future, then you need to adjust your style to be suitable for public consumption.

Someday, I’ll share some of my personal code with you guys.  My personal style is a lot like Pete’s — short, compact, and which uses the most amount of real estate on the screen, to reduce scrolling and line count as much as possible.  Yet, if I code something to share on the forums, I take time to try to unwind and expand those lines to make them as easily readable as possible.

_PRINTSTRING (bx + (bw - tw) / 2, by + fh * i), t$

For the above, I’ll go into search and replace all in the IDE and swap bx to BoxLeft, bw to BoxWidth, tw to TextWidth, by to BoxTop, fh to FontHeight, and t$ to temp$.

Now all my abbreviated variables, which made perfect sense to me, now hold some self-documenting meaning for others.  (The above would basically center multi-line text into a boxed area of the screen for me, while inside a loop.)

Of course, sometimes even the best attempts at making code understandable fails.  The other day, on Discord, I was questioned about some code I’d shared which was basically:

IF x THEN IF y THEN do_something ELSE do_other_stuff

To me, this makes perfect sense, and I didn’t think it needed unwinding further.  Others had never seen an IF inside an IF and didn’t know how to decipher that.  They didn’t know where that ELSE might relate to: the IF x, or the IF y.  Breaking it down to the following allowed them to instantly comprehend it:

IF x THEN
    IF y THEN do_something ELSE do_other_stuff
END IF

At the end of the day, coding style is all about attempting to code in a manner to make it easy for the user-base to read, understand, and work with the code in the future. 
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline MasterGy

  • Forum Regular
  • Posts: 125
  • people lie, math never lies
Re: QB64 REPORT S02E05: Coding Styles
« Reply #6 on: November 30, 2020, 01:23:19 PM »
Thank you, SMcNeill, for making it clear to me the importance of "coding style"! to understand, apply, see through others as well. Since I’m here on the board too, it’s like we’re all sitting by the campfire. Let everyone understand that when we go hunting, we can be more efficient!

Online Pete

  • Forum Resident
  • Posts: 2361
  • Cuz I sez so, varmint!
Re: QB64 REPORT S02E05: Coding Styles
« Reply #7 on: November 30, 2020, 01:56:31 PM »
Yeah, you guys go hunt. Me, I'm ordering pizza.

I remember a challenge at the QBasic forum to submit the most obfuscated code. I misread the post, and thought it meant the most efficient code. Still, I ended up winning the contest, anyway, go figure...

I can't say I could go back to my old ways, described in my last post, and still understand my programs. So my coding style has changed to accommodate my advancing age. What I play around with these days is variable naming. In the old days, I limited variable names to one or two characters, to save memory in QB45. I still have an easier time reading a program with short variables, than long descriptive names, but at some point, too many short named variables also gets hard to keep track of what's happening in the code.

I have wondered about what "standards" professional programmers, who work in groups, are held to. If one person is working on a project, all that matters is it works when it's compiled; but if many are working together, it may slow down the project if they all have to take the time to figure out another coder's style. For instance, when Mac asked me and two others to join him in his Danish chess program at the QBasic Forum, we put together a simple standard that worked for that project. It didn't require looking into any other contributors style. Simply put, each member of the group was required to certify that their module (contribution) worked. Mac's job was to join these three modules together, which would not require modification of any one contributor's code. If a problem was encountered in joining the modules, the coder of that module was asked to modify his code and thereby adapt it to the conditions needed for the joining process to be successful.

Pete
« Last Edit: November 30, 2020, 03:17:33 PM by Pete »

Online FellippeHeitor

  • QB64 Developer
  • Forum Resident
  • Posts: 2701
  • LET IT = BE
    • QB64.org
Re: QB64 REPORT S02E05: Coding Styles
« Reply #8 on: November 30, 2020, 03:13:41 PM »
@MasterGy I hope you didn't get offended for being mentioned, but your program was chosen as an example exactly for being so amazing but also so hard to read at the same time, and the fact you voluntarily decided to make it more readable was really kind. Glad to have you in the community! Now go fetch us some marshmallows.

🌳🏕

Online FellippeHeitor

  • QB64 Developer
  • Forum Resident
  • Posts: 2701
  • LET IT = BE
    • QB64.org
Re: QB64 REPORT S02E05: Coding Styles
« Reply #9 on: November 30, 2020, 03:15:40 PM »
You totally left out the discussion on coding in all caps, no remarks, no indentation, and no spacing between lines! You guys would have loved me, even more, back in the 1990's.

PETE

Shivers down my spine.

Offline MasterGy

  • Forum Regular
  • Posts: 125
  • people lie, math never lies
Re: QB64 REPORT S02E05: Coding Styles
« Reply #10 on: November 30, 2020, 04:43:02 PM »
I'm not offended! In fact, I felt honored to be mentioned. A handful of it is a team here, few already practice this language developed from dos. You are the ones who evaluate when something is made, so I owe you a debt of gratitude for being here. As for the campfire, I really understand the point!
For example. „Prog.hu” .Paid, educated application development group in Hungary. They produce value-creating things, and when I present, they don’t understand what I’m showing. They don't see the value, the marketability. Because there isn't. You are the ones who (for me) can really appreciate it.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1628
Re: QB64 REPORT S02E05: Coding Styles
« Reply #11 on: November 30, 2020, 05:57:25 PM »
Cool report.
it's fine to ear different way to think how  structuring the code, how to choose the name of variables, how .BM and .BI files can be thought and used.
Well, I'll find interesting experiences and opinions about group programming. The opinions left here above from Pete and Steve are    interesting points of view.
Programming isn't difficult, only it's  consuming time and coffee

Offline luke

  • QB64 Developer
  • Forum Regular
  • Posts: 242
Re: QB64 REPORT S02E05: Coding Styles
« Reply #12 on: November 30, 2020, 06:06:28 PM »
It's screaming snake case because it's snake case but in CAPS, and people writing in CAPS are SHOUTING...or SCREAMING.

I'll leave you with a few quotes:
Quote from: Donald Knuth
The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.

Quote from: Linux Kernel Coding Style
Don't put multiple statements on a single line unless you have something to hide.

Quote from: Donald Knuth
Programs are meant to be read by humans and only incidentally for computers to execute.

Quote from: Larry Wall
Real programmers can write assembly code in any language.

Spaces in variable names won't be a thing as long as we have "our universal preoccupation with BNF grammars and their various offspring". (Pratt, 1973).
« Last Edit: November 30, 2020, 06:30:01 PM by luke »

Offline Dav

  • Seasoned Forum Regular
  • Posts: 498
Re: QB64 REPORT S02E05: Coding Styles
« Reply #13 on: November 30, 2020, 07:27:19 PM »
You're invited to join us next time too, man. I know you're familiar with microphones.

Hey, Thanks for the invitation.  I'll have to think about that.    Maybe another one down the road instead?

Feels nice to be asked.

- Dav

Offline OldMoses

  • Seasoned Forum Regular
  • Posts: 412
Re: QB64 REPORT S02E05: Coding Styles
« Reply #14 on: November 30, 2020, 07:32:59 PM »
Fascinating discussion. I'll try to take some lessons from that. Since my coding kung fu style is mostly 'poo flinger', it might help.
Andy