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.

Improve this question
12
  • 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, 2013 at 20:40
  • 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, 2013 at 22:38
  • 7
    wtf/min
    – ratchet freak
    May 14, 2013 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, 2013 at 22:51
  • 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 (joelonsoftware.com/articles/Wrong.html). I think its especially helpful for dynamic typed languages like PHP.
    – superM
    May 15, 2013 at 12:44

2 Answers 2

Reset to default
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.

Improve this answer
1
  • 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.
    – Arseni Mourzenko
    May 15, 2013 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.

Improve this answer
2
  • 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, 2013 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, 2013 at 17:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.