Page 2 of 2

Re: What do you think about this coding standards document?

Posted: Sat Nov 14, 2009 6:50 am
by josh
If you don't indent your code to where it is easy to read (like you were saying), then the programmers gonna have a harder time looking at a "snarled method". A "snarled method" is a term from "working effectively with legacy code", meaning you have high cyclomatic complexity. If its harder to read the code at a glance you're going to try harder to make it clean code (kinda joking)

Re: What do you think about this coding standards document?

Posted: Mon Nov 16, 2009 1:12 pm
by infolock
Hey guys, great input thanks!

Let me respond to some of these comments:
superdezign wrote: But why attempt to state that a coding standard for one language should be the coding standard for another? Languages have different syntax and semantics. Making one global standard for all programming languages isn't possible.

And if it was, camel-casing is still superior in that it separates words just as well as underscores, but it is also quicker to type.
I'm not sure that this point makes much sense. camel-casing is one "method" of defining rules. While you prefer camel-case, go for it and use it. It's not what my standard calls for, so (as I've said before) feel free to use another standard.

Also, I think you said something along the lines of "We already have a coding standard". I'm not sure who the "we" is there, but if you mean all PHP developers I think that's not the case at all. There is no "one" coding standard to rule them all. There are hundreds of standards. Mine is just another one. I think this would just fall into the category of we agree to disagree when it comes to using one or the other. You see camel case as being the best method, I disagree. Either way, it's just a difference in opinion.
superdezign wrote: For interpreted languages like JavaScript and PHP, I agree with you. In terms of wrapping, there are coding standards for that too, like having no more than 80 characters per line in C++.
You are exactly right. I guess I was focusing too heavily in IDE's that allow non-wrapping code blocks instead of also taking into consideration editor's like console vi that cannot have this. I'm not so sure I could have a 80 character maximum though as it may make things like formatting huge multidimensional arrays diffucult. I'll have to look into this a bit more. Thanks for the input!
superdezign wrote: When going from one language to another, it is professional to adhere to the best-practice standards of the language. But to create your own standards based off of other languages does not apply.
I agree, but I did not create my own standard based on other languages. This is coming from coding in PHP only.
superdezign wrote:Everything that you mentioned is used in other languages. Since PHP is a new-age language, many of its developers have programmed in other languages and are familiar with other coding standards. The coding standards that we use are not based purely off of style or cosmetic appearance. They are based off of the most efficient coding standards. I'd say Java's standards are much closer to PHP's than C++'s, and that is partially because Java is more modernized and refined than C and C++, though based off of them.
I agree. Again, I don't think there is one set standard though that everyone follows, nor one that everyone agrees too. I tried to compromise though with this standard to adhere to many different styles though. To me, it's kind of like the argument of PHP vs .NET. Each side has their own likes and dislikes of the other. At the end of the day, it's up to the developer to choose which one they can use to do their jobs more efficiently.
superdezign wrote:The best practice coding standards are all laid out here and are very clear and brief.
This is Zend's own definition of a coding standard for teams using the Zend Framework (thus why their own site says "This document provides guidelines for code formatting and documentation to individuals and teams contributing to Zend Framework."). You do not have to follow it when writing your own PHP, nor do you have to use it when using Zend's framework. A lot of people use Zend's example, a lot of people don't. Once again, it's all about choice.
superdezign wrote: Maybe I should make my own programming language, too? Or maybe I don't because I don't see any reason to... :roll:
=] I'm not trying to bash ya man. Just saying that if ya don't like what I have, or ya don't like some of the things about Zend's, why not try making your own? No where is it written in stone to not do such a thing. Thus is the freedoms of being a developer imho.


Thanks a lot for the inputs guys. I really do appreciate it!

Re: What do you think about this coding standards document?

Posted: Thu Nov 19, 2009 10:42 am
by Jenk
Coding standards should be nothing more than "If it is not easy to read and maintain, it sucks."

The rest is zealous control of your developers. They are not monkeys, they are intelligent people.

Re: What do you think about this coding standards document?

Posted: Thu Nov 19, 2009 12:25 pm
by infolock
Jenk: I guess the question to that point would be, what determines what is easy to read and what is not? Standards, imo, do not treat developers as monkeys, but rather set rules in place that actually define (for that company or team) what is or is not easy to read. Not to mention, while you will allow people to format their code however they deem fit, when you attempt to maintain that code yourself and it doesn't look the way you are coding, you may (or may not, who knows) reformat the code so you can read it. This takes time away from development. While changing how you code is difficult and can even be a little annoying at first, you would be surprised just how easy it is to adept to other methods. Standards don't just format your mind, it formats the whole team's mind to say that this piece of code was written by a team, not an individual.

Re: What do you think about this coding standards document?

Posted: Thu Nov 19, 2009 1:00 pm
by Christopher
infolock wrote:There is no "one" coding standard to rule them all. There are hundreds of standards. Mine is just another one. ...
I think this is an erroneous statement. There are certainly "hundreds of standards", but all of those except one or two are used only by individual programmers or small groups. The vast majority of professional PHP programmers use very, very similar standards. Other than a few projects with PHP4 codebases, I have just not seen many differences at all. Code standards seem pretty standardized in PHP right now.
infolock wrote:Just saying that if ya don't like what I have, or ya don't like some of the things about Zend's, why not try making your own? No where is it written in stone to not do such a thing. Thus is the freedoms of being a developer imho.
I think my question is: Why do you have to like everything about a standard? It seems a little egotistical to expect everything to pleasurable to you. If you don't like something about industry standards it is usually the case that you are simply used to some style that the majority has discarded for various good reasons. It's not as though these standards are arbitrary and not arrived at through much input. And honestly, if you spend a little time with a standard you quickly get used to it. Really, these are just little formatting details ... it's not really about freedom and happiness.

Re: What do you think about this coding standards document?

Posted: Thu Nov 19, 2009 1:16 pm
by infolock
I guess this was a bad idea to post this. I'm not saying that some standards are right, and some are wrong. I'm definately not saying you should like everything about every standard. I just wrote this standard because it equates to what I and the developers I've worked with follow. We do absolutely what you're talking about, in that we adjust to specific standards and then don't follow certain portions of them. but where we don't follow them, I documented it and wrote what is basically what we follow. since it doesn't equal a specific standard, it was made into a standard. that's all. i'm not telling people to change their minds. sheesh.

edit: moreover, i guess this was intended to be helpful to any who wanted to see another type of standard that php developers like us follow. i wasn't trying to say "you should use this because I said so" lol... was just intended to be for educational purposes, and to also say you dont have to always follow mainstream coding styles. that it somestimes can make your team better by defining your own rules...which is all this standard really is (along with all other standards that i've ever read).

Re: What do you think about this coding standards document?

Posted: Fri Nov 20, 2009 8:01 am
by Jenk
Code standards are a waste of time, in my experience and opinion. "Readable and Maintainable" means exactly that, if you (someone else) can't read it, or can't maintain it because of readability, then it wasn't right. So simply put, just make it easy to read.

It's much more important to let any developer just flow, than to have them take the time to conform to a standard. Everyone has experiences with poorly written code, so everyone knows what to avoid. We've (in this office) never needed a document to tell us this, and others (friends/associates in other development environments) have agreed after deciding to just drop their standard(s) and just have some common sense about it. :)

Basically there just isn't any need to go into such detail about it. Does it *really* matter if the '{' is on a new line, or has a space before it?

Does it *really* matter that a variable is camel cased, when it can be read just as easily when not? Today's IDEs will still auto-complete for you. Though I will agree it is a pet hate of mine when an object's interface has mix-and-match casing/underscore members. :)

We also adopt the practice of Refactor Mercilessly so if it does bug you that a variable is not camel-cased, then just do it yourself, and eventually you'll get a happy medium :p

Re: What do you think about this coding standards document?

Posted: Fri Nov 20, 2009 8:15 am
by papa
Jenk wrote:Code standards are a waste of time, in my experience and opinion. "Readable and Maintainable" means exactly that, if you (someone else) can't read it, or can't maintain it because of readability, then it wasn't right. So simply put, just make it easy to read.

It's much more important to let any developer just flow, than to have them take the time to conform to a standard. Everyone has experiences with poorly written code, so everyone knows what to avoid. We've (in this office) never needed a document to tell us this, and others (friends/associates in other development environments) have agreed after deciding to just drop their standard(s) and just have some common sense about it. :)
I don't agree.

Where I work now for example, we have a lot of freelancers who create applications and when a project is complete developers here maintain those applications.
You save a lot of time for those people if you have some kind of standard how applications are made, even though there are very competent people creating those apps it's a lot of extra work for the people maintaining the code later on when they have to read different code standards for different apps.

Hope it makes sense.

Re: What do you think about this coding standards document?

Posted: Fri Nov 20, 2009 12:06 pm
by Christopher
infolock wrote:edit: moreover, i guess this was intended to be helpful to any who wanted to see another type of standard that php developers like us follow. i wasn't trying to say "you should use this because I said so" lol... was just intended to be for educational purposes, and to also say you dont have to always follow mainstream coding styles. that it somestimes can make your team better by defining your own rules...which is all this standard really is (along with all other standards that i've ever read).
I guess I am a little confused when you say "you dont have to always follow mainstream coding styles" when what you posted is essentially the 30+ year old K&R standard that is the most influential coding standard ever. It is also the coding standard used in PHP up through PHP4. The only real difference is that in PHP5 most PHP programmers now use capital/camel case for class/method names.

So I don't see anything wrong with your document, except that it is a little old school. And honestly, I think you should bite the bullet and start using camel case. I remember my initial resistance to it, but once you use it a short time it becomes quite natural. Maybe you think less of me for not having strong convictions, but I personally don't think code format style is that important.

Re: What do you think about this coding standards document?

Posted: Fri Nov 20, 2009 2:48 pm
by josh
I think at minimum there has to be some sort of arrangement so people aren't wasting development cycles changing from

Code: Select all

 
if( true ) {
} else if( false ) {
}
back to

Code: Select all

 
if( true )
 {
}
 else if( false ) 
{
}
and back...

(people will do it just to slack and look busy). For me it is the latter in PHP and the former in jQuery (because you have to to be valid)

Re: What do you think about this coding standards document?

Posted: Fri Nov 20, 2009 5:23 pm
by infolock
arborint wrote:So I don't see anything wrong with your document, except that it is a little old school. And honestly, I think you should bite the bullet and start using camel case. I remember my initial resistance to it, but once you use it a short time it becomes quite natural. Maybe you think less of me for not having strong convictions, but I personally don't think code format style is that important.
I agree with you arborint. I come from a wide range of languages, and when I coded in Delphi (pascal) camelcase was the way I wrote code. When I moved over to PHP, I had actually brought camel case conventions with me. Today though, I just dont use it as I don't feel the same about it once I moved to the K&R model. And yeah.. it's an old model, but to me (and the rest of the devs that I deal with), we agree that K&R just makes "our" development easier. I don't think that saying "camel case defines PHP naming conventions" is valid at all. I think that maybe...just maybe you have a pretty biased stance when it comes to that :) and honestly man, that's totally cool. developers are a very interesting breed, and each has their own philosophies and likes/dislikes. :)

(edit) And no.. i don't think of you less at all. you're a dev man, and in my book you're family (regardless of your beliefs)

@josh: good example

Re: What do you think about this coding standards document?

Posted: Mon Nov 23, 2009 5:08 pm
by Weirdan
infolock wrote:
superdezign wrote: For interpreted languages like JavaScript and PHP, I agree with you. In terms of wrapping, there are coding standards for that too, like having no more than 80 characters per line in C++.
You are exactly right. I guess I was focusing too heavily in IDE's that allow non-wrapping code blocks instead of also taking into consideration editor's like console vi that cannot have this. I'm not so sure I could have a 80 character maximum though as it may make things like formatting huge multidimensional arrays diffucult. I'll have to look into this a bit more. Thanks for the input!
From my experience (and I code exclusively in console vim, so it's first-hand experience) nowadays setting maximum line length to 120 characters is about right. It allows comfortable editing in split screen mode on larger displays (21+") and in single screen mode on smaller displays like 15" notebooks.

BTW, what did you mean by 'non-wrapping code blocks'?

Re: What do you think about this coding standards document?

Posted: Mon Nov 23, 2009 7:16 pm
by Christopher
infolock wrote:I don't think that saying "camel case defines PHP naming conventions" is valid at all. I think that maybe...just maybe you have a pretty biased stance when it comes to that :) and honestly man, that's totally cool.
I don't know where I or anyone else said "camel case defines PHP naming conventions." What I said is that camel case is now what most PHP5 programmers use. It seems like your main issue is with camel case. When I started with PHP5 I did not use camel case, but adopted it because most of the programmers I was sharing code with were using camel case. I can't say I like one style better than the other. I was used to underscores; now I am used to camel case. It was a very banal transition. I doubt anyone who knows me even noticed. ;)

Re: What do you think about this coding standards document?

Posted: Tue Nov 24, 2009 7:52 am
by superdezign
PHP is open source. In order to have a PHP application on your server, you will have the source. When making your application public, it will be open source. Because our source is not simply our own, we do not just conform to local standards. The Internet is a much bigger monster than that, and flowing against the current will not be to your advantage.

The standards are very clear, precise, and they all have purpose for readability and maintainability. Having a different coding standard means that you will have trouble importing other code from the community or sharing your own with the community. The first time I used SwiftMailer was before I was conforming to the standards, and seeing code formatted differently than you are used to makes reading it more difficult. Just like we can read our own handwriting, even if it's sloppy.

You've already conformed to the syntax of the language. What's wrong with conforming to the format?