Skip to main content
Topic: Coding styles (Read 2464 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Coding styles

Reply #1

Thats a fun set of statistics  :)

For PHP, ElkArte I could say generally follows, tabs,  opening/closing braces on separate lines, spaces after ,'s and control statements, etc  I guess thats mostly Allman / BSD style.  We have so-so adherence to any function naming convention, not that I think I could articulate what it should be :P 

We did try to write down the PHP guidelines here and I know we followed class names as Camel_Case, a bit different but that's what we did, and we were also good about anything private, function or vars, start with a "_" , which allows you to see at a glance what scope something is in.

Personally I've always used tabs and also generally always used {} on the same line, had to get used to a different convention for SMF and have kind of stuck with that since.  Fortunately you can program rules in to many IDE's so it takes care of a lot of that for you.

JS ... Hummm ... kind of along the PHP lines but also a bit of a mixed bag.  Tabs for sure, but you will see a mixture of function() and function ()  and lazy { or new line { ...  I think thats due to standard JS conventions and jQuery conventions as well.  Variables often hint at what they are,  iName, sName, oName (int, string, object).  We have done a few clean up passes with the scripts to help with formatting, documentation, removing old crud and hacks, moved some additional things to class structures, etc.  Has the same function naming problems as PHP.  Anyway things are more consistent but hard to pin down a style although it tends to follow what was done with PHP

Overall I think if you look through the code (JS and PHP) you will see that it is much better structured and consistent than what we started with,  But like all things, its a work in progress  :)

Re: Coding styles

Reply #2

Nice page! :D

The only thing I'm sure would make me run away from any codebase are spaces for indentation.
I really hate them.
I love my tabs, adjusted to 2 spaces width. <= And this is the reason I hate spaces: I like to have a compact view of the nesting, but if code is formatted with spaces I have to live with 4 spaces to indent, and this leads to a lot of space on the left that is a waste of space to me.
So now you know: the day you'll not want me as contributor, convert Elk to indent-with-spaces! :P

Apart from that, I too was used to have the {} on the same line and Spuds started asking me to use SMF style while reviewing a mod. Since then I stuck with it, and I think I like it. I also tried to use it with Java, but due to some concatenation of events it looked odd and I use the other convention with it.
Once upon a time I liked not to have spaces, now I scream every time I see the code clumped up without no spaces between variables, structures and so on.
Bugs creator.
Features destroyer.
Template killer.

Re: Coding styles

Reply #3

I wrote most of this years ago: http://wiki.simplemachines.org/smf/Coding_Guidelines

I conversed with a lot of the other SMF developers to get an idea of what they were doing. So, I eventually just wrote it all down.

I generally stick what I wrote years ago, except I anything that is a language construct (require, include, continue, etc) I never put parenthesis after it. I also use a ton of PHPDoc and use the /** comment */ style now.

My functions are pretty much always camelCased and my properties/variables are $lower_underscored; I always add the visibility to the property or method. I don't use $_ to denote a protected/private visibility because my IDE does it. That way I don't have to refactor anything if I change the visibility. Also, less character to type.

As for HTML, whatever HTML5 allows, I'm good with. I usually close my <li> but sometimes I don't and I don't care one way or the other.