Flyspray - The bug killer!

  • Status Confirmed
  • Percent Complete
    0%
  • Task Type TODO
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Low
  • Reported Version 1.0 devel (github master)
  • Due in Version 1.1 devel
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by Psychokiller1888 - 07.03.2015
Last edited by Psychokiller1888 - 07.03.2015

FS#1955 - Codestyle

So, the new website is now online, the codestyle part is empty and I think we need to speak about them...

I can happily reformat the whole project once we have decided the whole thing. Don't forget, too strict code style leads to code style not being respected, so crap like max line length should be avoided. I personnaly don't know anybody coding from their mobile phones. I sometimes do check some code on it, but long lines never disturbed me as long as the line is not 5k chars long.

I think we should go for a standard one.

Things like:

- Do use brackets even if single lined condition
- Variable names have spaces replaced by the next words first letter in capital, start with a lower case
- Same goes for functions
- Etc etc. Pretty much of PSR-1 maybe 2

What I don't understand is the use of spaces, and I'd be for tabs instead of 4 spaces (some files use 2 spaces, some 3...). Most of the dev tools are by default set to use tabs and not spaces. And be seeing the code now we see that it clearly. So i'd be for reformatting into tabs, the whole, and same time fixing the broken identation in every files.

I could write it down for the website

Project Manager
peterdd commented on 09.03.2015 11:29
  • Do use brackets even if single lined condition

Yes. :-)

  • Variable names have spaces replaced by the next words first letter in capital, start with a lower case

I have no personal preferences. camelCase is popular in Java if I remember right.
Because variable are case-sensitive I would keep them lowercase to avoid hard to detect errors. (e.g. a $pwok vs. $pwOk)

  • Same goes for functions

I'm find with camelCase here. Functions are case-insensitive in PHP by the way, but lets keep them consistent within the Flyspray project.

  • What I don't understand is the use of spaces, and I'd be for tabs instead of 4 spaces (some files use 2 spaces, some 3...). Most of the dev tools are by default set to use tabs and not spaces. And be seeing the code now we see that it clearly. So i’d be for reformatting into tabs, the whole, and same time fixing the broken indentation in every file.

I recently discussed this with members of a local programming user group. I argued for tabs, they argued for spaces. Their only left valid argument for spaces over tabs was on alignment of multliline if() conditions where u align them by the first line condition.

if(  $x>1
  && $x<10
  && $y==1
){
    #blabla
}    


But for this special case I personal prefer the TABSSPACES solution.

So a tabbed multiline if condition looks this way: T = 1 TAB, S = 1 SPACE

TTif(  $x>1
TTSS&& $x<10
TTSS&& $y==1
TT){
TTT#blabla
TT}    

So I vote for TABS over SPACES with this multiline condition exception.

Project Manager
Psychokiller1888 commented on 09.03.2015 11:48

- A variable containing the owner's name should be called:

$ownerName ⇒ camelCase, imo the widest used one

and not $owner_name / $OwnerName / $Owner_Name

- CONSTANTS should be uppercase ⇒ OWNERNAME
- class vars should be suffixed with underscore ⇒ _ownerName. That makes assignement easier:

public function setName($name)
{

  $this->_name = $name

}

- About alignement, I do the same as you for mutliline if there's need to align

Functions use getters and setters:

Only returns or calls other functions for work, nothing else
public function getName()
{
return $this→_name;
}
Only sets or calls other functions for work, nothing else
public function setName($name)
{

  $this->_name = $name;

}

- Function names do follow camelCase

- Class names have a capital first letter ⇒ class PresidentOfUnitedStates

- Class constructor __construct() is optional in my opinion and I don't think we should force the use

- A space follows selectors, but not the parenthasis ⇒ if ($foo){
}

- Use single quotes instead of double quotes, when applicable

Project Manager
peterdd commented on 09.03.2015 17:28

Getter and setter for variables look always so bloated to me.

  • A space follows selectors, but not the parenthasis ⇒
    if ($foo){ }

I like

if($foo){ }

too. For me "if" looks always like a function and inside are the parameters. :-) And I don't see the profit of typing an additional space there.
But I'm ok with it if the other people want a space there in the coding guide.

  • Use single quotes instead of double quotes, when applicable

Yea, I prefer also single quotes when applicable. It's less code noise than double quote and PHP has not to look if there are $variables in a string.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing