4

Our specific situation is that we are creating an agreement between ourselves and another team for shared control or use of a PHP based web application that we have been building. We have a set of standards and conventions documented in our technical specs. However, I have been asked to define them in terms of an industry standard.

I am aware of different terminology for coding conventions. Hungarian notation, CamelCase, for example. And some defined standards for very specific things, PSR-0 for example covers namespaces in PHP.

It seems the point is to try to give us stronger ground in the agreement, by pointing to industry standards rather than an arbitrary standard we set forth. They're looking for things like the PSR-0 or an ISO#### or IEEE#### that we can point to.

My personal concern is that I've spent the time working with the team to show them the standards we have and to get buy in on the bigger parts of it. So I'm worried we'll either end up having to conform to some standard that doesn't match how we like to program, or the better case will be picking and choosing pieces of standards if they exist, to fit our current conventions.

Anyway, the core of the question is, Are there any industry standards regarding code quality, coding processes, or other areas that would help us keep their programmers from making disruptive or difficult to maintain code? I realize we can't prevent it, but if we can point to the agreement, at least we have recourse other than refactoring or recoding it ourselves.

Any other thoughts or suggestions would be helpful.

CLo
  • 368
  • 1
  • 11
  • 4
    Cyclomatic complexity (which can be measured by some IDEs) and coding style guidelines (which can be enforced in the IDE) come to mind. – Robert Harvey May 14 '13 at 20:40
  • If you have been building already and you have a standard, insist they use it. No sense rebuilding what you have doen to change to some mythological industry standard. Being consistent with a current standard no matter how common or uncommon it is would be far more important. – HLGEM May 14 '13 at 20:54
  • Not quite what you're looking for and initially not developed for PHP, but App Hungarian Notation might be helpful (http://en.wikipedia.org/wiki/Hungarian_notation). – superM May 14 '13 at 21:00
  • possible duplicate of [How would you know if you've written readable and easily maintainable code?](http://programmers.stackexchange.com/questions/141005/how-would-you-know-if-youve-written-readable-and-easily-maintainable-code) and of [What parts of your coding standard contribute to quality code?](http://programmers.stackexchange.com/questions/2654/what-parts-of-your-coding-standard-contribute-to-quality-code) and of [What should be in a coding standard?](http://programmers.stackexchange.com/questions/15636/what-should-be-in-a-coding-standard) – gnat May 14 '13 at 22:26
  • 3
    @gnat I'm not seeing how this is a duplicate. There's a big difference between "what is the industry standard for X?" and "what makes for good standards?" – Matthew Flynn May 14 '13 at 22:38
  • 7
    [wtf/min](http://www.imod.co.za/2008/02/07/wtf-measure-of-good-quality-code/) – ratchet freak May 14 '13 at 22:46
  • 2
    Coding *style*, like naming conventions, isn't code quality. Code quality is something along the lines of so many defects per thousand lines of code. Obviously, some hard to understand and modify program that is bug free (high quality in the defect rate sense) is inferior in some sense compared to a bug free program that is easy to understand and change. It's not clear whether stretching the definition of "quality" to cover that difference is a good idea, rather than calling that something else, like maintainability. – Kaz May 14 '13 at 22:51
  • @HLGEM I should probably mention I work for the state, so your logic is the first thing I presented, and yet I'm here. – CLo May 15 '13 at 12:28
  • @superM Thanks, though Hungarian is more focused on communicating data types within variable names. PHP is not well suited for this, and with PHPDoc and Eclipse IDE we can actually get that benefit already. – CLo May 15 '13 at 12:29
  • @Kaz You're right, but I see style as a way of helping to obtain quality. I'm also interested in enforcing things like unit testing as a requirement, which could be seen as a self check on quality. Quality is the end goal obviously, but with a 3rd party my thought is "if it doesn't work, your job isn't finished" but "if it works but is hard for me to maintain" how can I argue that your job isn't finished? – CLo May 15 '13 at 12:32
  • 1
    @Chris, what you say is true for System Hungarian, not App Hungarian. The latter is for indicating the purpose of the variable in its name (http://www.joelonsoftware.com/articles/Wrong.html). I think its especially helpful for dynamic typed languages like PHP. – superM May 15 '13 at 12:44
  • 1
    @superM I hadn't seen that clarification so well defined before, thanks for the article. For my specific situation, we're preferring more descriptive names. It's an interesting discussion I'd be willing to have outside of comments (after I ran out of space originally). But the short of it is, we tell junior programmers to think in terms of sentences. Instead of `sRequest` or `usRequest`, "My `cleanRequest` array has a cleaned version of all my Request variables." – CLo May 16 '13 at 17:14

2 Answers2

4

Well, there are the standards put forth by the PHP Framework Interoperability Group.

Then there are the standards put up in reaction to the PHP Framework Interoperability Group: The Difinitive PHP Style Guide.

And then there's Apache's style guide.

So, no. Nothing that's been agreed on by the industry.

Matthew Flynn
  • 13,345
  • 2
  • 38
  • 57
  • 1
    It's funny that Apache's style guide itself has no style at all. No CSS. Not even headers. It looks like the document was specifically done to be as unreadable and unusable as possible. Especially when compared to [Google style guides](https://code.google.com/p/google-styleguide/). – Arseni Mourzenko May 15 '13 at 20:13
4

Industry standards are subjective. The field is so full of competing ideas that you can always find someone who will prefer another approach over even those that are recommended in some manifesto. What matters is consistency within the organization. That trumps industry standards.

The reason being is that sometimes organizations have good cause to take a less favored approach. For example, I have worked on a lot of government contracts. The government has a tough time attracting and keeping top-tier developers. As such it tries to code in a very general, entry-level developer kind of manner. They want it to be easy to bring in new developers. They also want it to be easy for developers to move between projects. Thus, they try to keep the coding style across projects homogeneous and explicit. By explicit I mean they favor coding things outs vs. having things magically happen (look at an ActiveRecord definition in Rails and you'll know exactly what I mean by "magic").

No two organizations have the exact same priorities. As such, there may be good reasons for their standards to vary. Consistency is what matters.

Mario T. Lanza
  • 1,700
  • 1
  • 13
  • 22
  • 1
    They don't really have good cause. They *could,* but that would require that they have a good understanding of the tradeoffs they're making, and a lot of times they don't. +1 for consistency trumping standards. – Robert Harvey May 15 '13 at 19:49
  • @RobertHarvey I agree a lot of times conventions are just used without proper understanding. There seems to be an idea of "Imposing Conventions" rather than "Selecting Conventions". Before defining most conventions I'll talk with others in the team to see what they think and to solicit alternatives. – CLo May 16 '13 at 17:50