User:Crutchy: Difference between revisions

From SoylentNews
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 13: Line 13:
Perl programming style guide:<br>
Perl programming style guide:<br>
http://perldoc.perl.org/perlstyle.html
http://perldoc.perl.org/perlstyle.html
Just to start the ball rolling ("borrowed" from perl.org):
* closing curly bracket of a multi-line BLOCK should line up with the keyword that started the construct
* 4-column indent
* Opening curly on same line as keyword, if possible, otherwise line up
* Space before the opening curly of a multi-line BLOCK
* One-line BLOCK may be put on one line, including curlies
* No space before the semicolon
* Semicolon omitted in "short" one-line BLOCK
* Space around most operators
* Space around a "complex" subscript (inside brackets)
* Blank lines between chunks that do different things
* Uncuddled elses
* No space between function name and its opening parenthesis
* Space after each comma
* Long lines broken after an operator (except and and or )
* Space after last parenthesis matching on current line
* Line up corresponding items vertically
* Omit redundant punctuation as long as clarity doesn't suffer
If anyone has any others or wants to change any, feel free to do so. Maybe add a reason/background in change summary just so others know where you're coming from.


We should maybe make a wiki page for coding style and develop it so that all our code is readable and consistent regardless of author.
We should maybe make a wiki page for coding style and develop it so that all our code is readable and consistent regardless of author.

Revision as of 11:12, 23 February 2014

PHP/SQL/HTML/CSS and Delphi (Object Pascal) are my preferred languages.
I'm pedantic about code etiquette (indents, spaces, etc).

New to Perl but interested in learning. I have a basic perl virtual host set up on my dev machine.

Look out for me on #Soylent IRC.

Watch pages:
Style
CSS Work

Code style

Perl programming style guide:
http://perldoc.perl.org/perlstyle.html

Just to start the ball rolling ("borrowed" from perl.org):

  • closing curly bracket of a multi-line BLOCK should line up with the keyword that started the construct
  • 4-column indent
  • Opening curly on same line as keyword, if possible, otherwise line up
  • Space before the opening curly of a multi-line BLOCK
  • One-line BLOCK may be put on one line, including curlies
  • No space before the semicolon
  • Semicolon omitted in "short" one-line BLOCK
  • Space around most operators
  • Space around a "complex" subscript (inside brackets)
  • Blank lines between chunks that do different things
  • Uncuddled elses
  • No space between function name and its opening parenthesis
  • Space after each comma
  • Long lines broken after an operator (except and and or )
  • Space after last parenthesis matching on current line
  • Line up corresponding items vertically
  • Omit redundant punctuation as long as clarity doesn't suffer

If anyone has any others or wants to change any, feel free to do so. Maybe add a reason/background in change summary just so others know where you're coming from.

We should maybe make a wiki page for coding style and develop it so that all our code is readable and consistent regardless of author. Also looking for one for other languages used for Soylent: CSS, HTML, JS, SQL

Slashcode

IHMO there are way too many folders nested in the slashcode source tree. There may be good reasons but I generally prefer a flat filesystem (as much as possible anyway) for code accessibility. Also helps to reduce likelihood of duplicate filenames. What do other devs think of prefixing function names with source filename?
For example, main() function in article.pl becomes article__main()
Not suggesting that it all be changed to suit this convention right away, but might be handy for new functions to make it easier to figure out where things are declared.