I'm in the IRC atm, as are a few others - we should discuss it there?

irc?
got a good idea myself

Added a couple of planning pages in the Wiki:

• Project Concepts - deciding what to make.
• Coding Standards - how we code.

I have a few problems with the proposed coding standard, i have posted a comment voicing my opinions.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

My thoughts on the proposed standards:

1. Indentations
The problem with different tab spacing can be solved by having tabs set to five spaces. Most IDEs can do this.

2. String concatenation
Why no space? It makes the code cleaner looking to do so. I would recommend having a space before and after the period.

3. Single line if statements
It is not a good idea to allow single line if statements at all because it is always possible a second line will be needed. A programmer could easily accidental add a line with no brackets. Then boom, you have a bug on your hand. Even if it does not take a long time to resolve, it is still a good idea to use brackets.

4. Comparison operators
This is PHP, not basic. Use the C++ style operators (&& and ||) in if statements.

5. Ternaries
Ternary operators are harder to read and edit than normal if statements and should probably be disallowed completely.

Concepts
CMS -Probably too large to make and too heavy to maintain since we have a small volunteer force. And not to be politically incorrect, most of the force won't be competent enough to pull this off.
Framework -Too many out there.
Text Based Game -The purpose of this project is to give an open source script people can use. Doesn't it seem like a dumb idea to give everyone the same game they can host? It would be pretty much useless and we probably wouldn't have many takers. Plus, a game would be really heavy on the server so anyone who uses it would have to decent server. I don't think we would even want to put it on our box.

__________________

A alternative to Gallery2 and all it's bloat would be nice, not to say coppermine isn't nice - but thats about it as far as respectable gallery scripts go.

Im quite flexible with the coding standards, i don't mind how we should do it.

About the project choises;
- I like the CMS, just because i do... Don't know why.
- The Gallery idea came from me, that's because there are simply no professional looking, simple and fast open source galleries. I think we can really get some attention with this one.
- I have used Arctic (Arctic Tracker - Issue and Bug Tracking Tool written in PHP) at work and i love it, the only problem is that it's paid software. So i also like the planning system etc..

__________________
Nunchaku! Who doesn't like martial arts? =)

Count me in on the project, I've coded PHP for quite a long time. peter[dot]bastian[at]gmail[dot]com. Oh and btw, are we going to code for only PHP5 or both PHP4 and PHP5? Would prefer PHP5 as it has so much better OOP.

I've been using Kohana lots and their coding style is my preferred choice. That said, it's a community project and up to us to decide what we want.

I'll respond directly to VI's comments from the point of view of someone who's been using this style for a long while.

Please do NOT use spaces for indenting, or tabs for aligning. Tabs should be tabs and spaces should be spaces. Most IDEs can handle things perfectly fine to use the suggested style.

I've actually come to my own conclusion that using no space makes the code look cleaner, especially with longer lines of concatenated strings.
It's always possible for a programmer to delete an opening/closing bracket, to make a typing mistake or otherwise do something wrong. Using the suggested style, I can scan the code for conditions where the normal flow of execution is broken (returns, continues, etc) very quickly simply by notice where there aren't curly braces.

Cleanliness is next to godliness. Personally I think '&&' and '||' are ugly beasts (and all too easy to typo, right?) compared to 'and' and 'or'. When used in uppercase (as recommended) they provide a clearer separation of the conditions, IMO.
Why take eight lines of code when one will suffice? The aim of these standards is to make things neat and tidy. If a ternary statement is all messy then by all means separate it out into neater code. I'd also argue the point that ternary operators (unless abused) are easier to read and edit than normal if statements; one line is easier to scan (especially if it's always (SIMPLE_CONDITION) ? IF_TRUE : IF_FALSE).

From the items discussed, and the community here at TalkPHP, I think the best of the bunch of ideas already suggested would be to go with a photo gallery system. There are lots of component parts for people to work on, it'll cover a plethora of approaches to solving (application) design issues, etc..

A final note, the Kohana coding style is aimed at experienced PHP programmers and meant to keep things consistent throughout that code base. Firstly, we're probably not all at the same level (ie, contibutors might get confused over ternary operators) and secondly, we're not writing code to go into the Kohana project. Put in your own thoughts and ideas.

Regarding ternary operators I usually use this methodology:

If an if statement has only one simple function use a ternary operator. For others use a full if. For example:

Personally i don't like ternary operator at all. Just a simple if / else is very easy to read, so i vote for no ternary operator at all :>

__________________
Nunchaku! Who doesn't like martial arts? =)

I am for ternary operators whats the point of..

When one could just do this...

Given this is a very simple example and we've not even gone into nested ternary operators.

Don't think im having a go at anyone, these are my opinions.

I disagree, will you explain why you think using spaces is evil. I dislike using tabs becaus they can be interpreted differently by different editors across different operating systems and thus results in code like this:

Which i think you will agree is a pain in the arse, whereas if you use spaces the size of a space is uniform thus 4 spaces is always the same length.
Spaces don't take up much more space, not worth writing home about anyway so therefore 'Spaces make the file size bigger' isn't an issue. All editors i have used (vi,nano,emacs,kate,gedit ....) have handled spaces properly, in any case you don't have to sit there repeatedly hammering space like most people think as all proper editors will expand tabs to spaces for you.

Ternary conditionals
Ternary's should be allowed as they allow a quick and simple way of conditionally assigning variables etc and are easy to read if written properly, but at my work we have a rule that nesting them is punishable by death, for justification Salathe posted an excellent example : Ternary Conditionals

Concatenation operators
Spaces should pad concatenation operators for readability, but I'm not too fussy about this.

Inline conditionals
I have to agree with VI on this, conditional statements without proper demarcation is bad, takes a sledgehammer to readability and introduces bugs where they could have easily been avoided.

Logical operators
The main difference between logical operators 'AND' and '&&' for example is operator precedence, php.net does an excellent job (for once) at explaining:
As you can see they operate differently under different circumstances, therefore both may be needed.


Its good to have a healthy debate on the matter otherwise we will never have code that is liked by all. We have just been through this at work and it took quite a while to agree on certain things (like brace placements and naming conventions) but we agreed eventually after seeing both sides of the proverbial coin.
As i have said before I am willing to change some of my coding styles although I will need evidence that they will give an advantage.

Surprisingly were not arguing over brace placement.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

Good idea :P

haha , ok let the arguments begin!

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

v2 has decreased the difficulty in using nested IF statements for me, and lowers the chances for bugs (in my opinion) so I vote for V2 first, and if it must be done, v1. V3 is just annowing to space the tab, it doesn't do anything for readability and is easy to skip/forget.

AAAAAND as for the "&&" + "AND" argument, I like && from working with C++. I think that anyone that has worked with C++ will agree. "AND" can be confused for a word while scanning a lot easier than && can anyway.

__________________
Signatures are nothing but incriminating.

+1 for ^

As a C++ programmer, I completely agree with you.

__________________

I would rather have

__________________
Signatures are nothing but incriminating.

I've had quite some hours in C++ but i disagree with you (yeah im a stubborn Dutchman). When you see the following lines:

The second is more understandable in my opinion.

About the if blocks, as the stubborn dutchman i like the following style:

But like I said a few posts ago, i don't give much about programming styles. Just tell me what to use and I will. :)

I noticed many people like the idea about the gallery project. How about discussing more about the type of project, those who don't like the gallery please let us know and tell what you prefer.

__________________
Nunchaku! Who doesn't like martial arts? =)