As the two main contributors, Victor and myself have come up with the following standards. We ask that people that wish to contribute to the PRISM project follow these standards.

1. We use LF (Linux & Git Standard) style line encodings on our files.
   
2. Use tabs for white space, and the tab width should be equal to 4 spaces.
   
3. Lowercase vars & function names. Uppercase classes
   
4. We ask that you make the function names as clear and as concise as possible.
   
5. We don't follow any style standards as far as source code formatting, use what you wish.
   

Please use this thread to discuss any additional standards you wish to add or use this thread to talk about any style standard you think no longer fits or should be out right removed in the first place.

I'm sure there where one or two more, but I can't for the life of me remember what they where. Victor, can you think of the ones that I missed?

Not sure #3 is a good idea, especially when styles are mixed within a single file. Personally I'd rather adopt someone else's style than mix them up.

Quote from morpha :

Not sure #3 is a good idea, especially when styles are mixed within a single file. Personally I'd rather adopt someone else's style than mix them up.

Funny you should say that. Me and victor where passing back and forth our programming styles (Not that the differ that greatly.) from file to file to keep the style consistent.


And I was right, I did forget a few things. So I'm going to edit my first post now!

Well I'm most concerned about readability when it comes to scopes. If
and
are mixed within a single file, readability will suffer tremendously. If we leave it like that, we should at least enforce curly braces even for one-liners, which is good practice anyway.

I approve of the changes though, LF and 4-space wide tabs are my default settings anyway

Quote from morpha :

Well I'm most concerned about readability when it comes to scopes. If

if (...) {
}

and

if (...)
{
}

are mixed within a single file, readability will suffer tremendously. If we leave it like that, we should at least enforce curly braces even for one-liners, which is good practice anyway.

Yeah, I do some single line stuff, that I don't curly brace. I guess you have a point, but I'm not sure if it's that big of a problem. It might be, soon. But with like only 3 people throwing around code right now I don't see it being much of a problem. That and two of the three have already said that what ever is already in use in the file is the style that they use. So there's that.

I'm more of a curly brace on it's own line kinda guy, because that does help with readability, in some situations. But an argument can also be made for having them on the conditional line, with it being more to the standard of allowing one line statements following one line conditionals just looking correct with each other. So it really depends. Programming style vary greatly, and for the most part, I don't care. I can read the code anyway. If you want to program one way, and they want to program another, ok fine. It does not bother me one bit.

If this has enough people that would like this standard imposed, I have no problem with that too. We could consider starting a poll on the subject, should there be enough voices to speak out for this.

Quote from morpha :

I approve of the changes though, LF and 4-space wide tabs are my default settings anyway

I approve of your preferences

utf8 or MacRoman?

And in no. 3 you probably just refer to the first character of the name... (I hope )

yup

$varName
functionName()
class SomeClass {}

Personally.. I prefer
if(...){
<code>
}

Makes for reading a bit easier where an if statement ends, by looking for the matching brace.. not looking for the next line, then the match.

i used to agree, until i started to sometimes have very long if() statements, so i started to wrap them. Having the curly braces on a new line is nicer then.


looks/reads better than


but yeah 90% of my scripts use if () {

Quote from Victor :

but yeah 90% of my scripts use if () {

I find that I use what ever is appropriate at the time. I know lots of programmers have holy wars of this sort of thing, but ... I just don't care! There is so much more to be done, I really don't mind how you program as long as it works and it follows the rules outline above.

I agree that which style you prefer doesn't matter, but you should pick a style and stick to it. Nothing uglier than a codebase where different contributors use different conventions. If the PHP language has an official style-guide you should use that.

At least stick to the file-style if you edit an existing file

Quote from DarkTimes :

If the PHP language has an official style-guide you should use that.

I don't think it does, but I really never looked. So I'll do that after this commit.

I refuse to include underscores in my function names though

vb uses php style naming though (so with underscores and no uppercases at all). But they do put their curly brackets on a new line. I think it doesn't matter what you use (hence you CAN do it however you want), but yes, let's just stick with one style like everyone said The one used atm seems fine to me.

I guess PHP makes function naming extra confusing, as seemingly even the guys that wrote the standard library couldn't agree on a consistent naming convention. I find it confusing that function names, and even the order of parameters, can be totally different from one function to the next.

Quote from DarkTimes :

I guess PHP makes function naming extra confusing, as seemingly even the guys that wrote the standard library couldn't agree on a consistent naming convention. I find it confusing that function names, and even the order of parameters, can be totally different from one function to the next.

Yeah, that's why I program with the PHP manual open. Because, you just never know some times. It's impossible to remember the correct order for all of the functions so I find myself having to lookup one thing most of the time I program.

Btw Dygear, you are naming your classes wrong

Quote from GeForz :

Btw Dygear, you are naming your classes wrong

Shhh! If you don't tell anyone, no one will notice!

Ehh, what did I do? What classes are wrong?

abstract class plugins
abstract class struct
class theTime

Not uppercased :/

Quote from GeForz :

abstract class plugins
abstract class struct

These where made before the standard was settled on.

Quote from GeForz :

class theTime

It's a plugin class. I don't expect plugin devs to follow this standard as their file names must match their class names, it also must match their section names, but that's neither here not there.