Difference between revisions of "Coding Standards"

From Funtoo
Jump to navigation Jump to search
(Undo revision 34515 by Funtoomademe42percent (talk))
Tag: Undo
 
Line 1: Line 1:
== Blitz BASIC Coding Standards In A Nutshell ==
== Basic Coding Standards In A Nutshell ==


* code good
* word wrap at 160 characters
* else if
* use tabs, not spaces, for indentation
* else if
* use a tab size of 4 characters (tab size can be adjusted but it affects when you reach the magic 160 char wrap limit)
* else if
* comments on separate lines, at same indent level as code (sections can be marked by 'outdented' comments)


== Word Wrap ==
== Word Wrap ==


Modern editors do a mediocrre job of displaying very long lines of text, and modern displays don't have sufficient resolution for displaying any more than 80 characters per line, even at 1024x768 resolution. You should definitely split an elegant single-line piece of code into *multiple* lines just for the sake of keeping the whole thing under 80 characters. It's especially bad if you don't take, say, a 100-character line and split it into ''more'' than two lines for the sake of keeping it under 80 characters in length. Just be sure to maintain Apple IIe with 80-column card compatibility.
Modern editors do a good job of displaying very long lines of text, and modern displays have sufficient resolution for displaying much more than 80 characters per line, even at 1024x768 resolution. You should definitely not split an elegant single-line piece of code into multiple lines just for the sake of keeping the whole thing under 80 characters. It's especially bad if you take, say, a 100-character line and split it into ''more'' than two lines just for the sake of keeping it under 80 characters in length. But you need or want to use multiple lines to keep your code readable, more power to you. Don't just do it to maintain "Apple IIe with 80-column card compatibility" for any reason. That's just silly.


== Tabs vs. Spaces ==
== Tabs vs. Spaces ==


There is no space between :green_heart: and @redacted, smh.
Tabs and spaces had a fight. Tabs won. They're easier to deal with and allow configurable indentation for those who require it. I don't care what some other group or organization says the convention is. If you don't want to use tabs because you want all your end-of-line comments to line up beautifully, then I have a solution: don't use end-of-line comments (see the next section) and you'll be fine.


== Comments ==
== Comments ==


Here's why I think annotating your code for others is fucking stupid. Now, I'm not Jesus of Nazareth, so I don't need to be a fucking saint here, alright? If you can't understand what my hick Ohiobraskan ass is doing with my shitty C++ or lua code, do you deserve annotations or comments? No. Learn how to code from Linus or some other amateur nigger, not me. My e-girl who has her name in Alabama's #2 ABDL supporter's twitter bio (only the horny one tho, if we're gonna look on the bright side, here), gives good CSS lessons. But I'm not in the business of giving out C++, BASIC, or node.JS lessons, sorry.
Add comments that provide some insight into your code, and that help to provide context. Also, because we use tabs, place comments on their own lines, separate from source code, ideally separated by a blank line above and below unless you are verbosely commenting every line of code. This also encourages longer, more descriptive comments that may span multiple lines. If you span multiple lines, use a consistent right margin of 160 characters. Comments help you understand your code when you come back to it a year later, so you are adding descriptive comments for yourself as much as for others. Include information you would find helpful if you had a sudden case of amnesia. They are especially important for free/open source software that needs to be maintained by various people over the years.


== Profanity ==
== Profanity ==


[Intro: Murder Mike & Du-Rag]
Do not place any profanity in source code comments or variable names. It just makes you look unprofessional, silly and incompetent.
Yeah, motherfucker
Sup, nigga
Gangsta Rap, nigga
Nigga
 
[Verse 1: Du-Rag & Murder Mike]
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
I'm one-hundred-percent nigga
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
I'm two-hundred-percent nigga
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why do police hate niggas?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
They hate us 'cause our dicks is bigga
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you call yourself a nigga?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
'Cause I'm a motherfucking nigga
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you drink so much beer?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
I don't drink beer; I drink malt liquor
 
[Refrain: Murder Mike]
'Cause I'm a nigga!
I'm a motherfuckin nigga, man, I ain't all that African-American shit
Fuck that I'm a nigga, I ain't mixed, I'm a nigga
N...-I-G-G-A
Nigga, you already know
 
[Verse 2]
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you eat so much chicken?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why won't you make it in my kitchen?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you call them hoes bitches?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
'Cause them hoes is bitches!
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you stay in the hood?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
'Cause I don't like livin' by peckerwoods
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you ain’t got no job?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Seven dollars an hour won't feed my dog
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why yo' pants gotta sag?
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
'Cause hand-me-downs is all a nigga had
Nigga, nigga, nigga, nigga, nigga, nigga, nigga
Why you scared to go to court?
Shit, 'cause the judge look just like that motherfucker that put our ass on the boat and made me a nigga
 
[Outro]
Mama Rag is a nigga
Durag is a nigga
Ballistics is a nigga
And I'm Uretha's nigga
Nigga




[[Category:QA]]
[[Category:QA]]

Latest revision as of 10:47, November 30, 2020

Basic Coding Standards In A Nutshell

  • word wrap at 160 characters
  • use tabs, not spaces, for indentation
  • use a tab size of 4 characters (tab size can be adjusted but it affects when you reach the magic 160 char wrap limit)
  • comments on separate lines, at same indent level as code (sections can be marked by 'outdented' comments)

Word Wrap

Modern editors do a good job of displaying very long lines of text, and modern displays have sufficient resolution for displaying much more than 80 characters per line, even at 1024x768 resolution. You should definitely not split an elegant single-line piece of code into multiple lines just for the sake of keeping the whole thing under 80 characters. It's especially bad if you take, say, a 100-character line and split it into more than two lines just for the sake of keeping it under 80 characters in length. But you need or want to use multiple lines to keep your code readable, more power to you. Don't just do it to maintain "Apple IIe with 80-column card compatibility" for any reason. That's just silly.

Tabs vs. Spaces

Tabs and spaces had a fight. Tabs won. They're easier to deal with and allow configurable indentation for those who require it. I don't care what some other group or organization says the convention is. If you don't want to use tabs because you want all your end-of-line comments to line up beautifully, then I have a solution: don't use end-of-line comments (see the next section) and you'll be fine.

Comments

Add comments that provide some insight into your code, and that help to provide context. Also, because we use tabs, place comments on their own lines, separate from source code, ideally separated by a blank line above and below unless you are verbosely commenting every line of code. This also encourages longer, more descriptive comments that may span multiple lines. If you span multiple lines, use a consistent right margin of 160 characters. Comments help you understand your code when you come back to it a year later, so you are adding descriptive comments for yourself as much as for others. Include information you would find helpful if you had a sudden case of amnesia. They are especially important for free/open source software that needs to be maintained by various people over the years.

Profanity

Do not place any profanity in source code comments or variable names. It just makes you look unprofessional, silly and incompetent.