While browsing through some old code at work (not MUD code, but relevant none the less) I came accross an attrocious cpp file, the various authors had come from different coding backgrounds (4 of them, an engineer used to  fortran, a java programmer, a C prima donna - not an attack at C users just this guy, and an amateur VB *shudder* user). 2 of them used a consistent style (alas, only within their own code, and not with each other) and the others were inconsistent even within their own functions *boggle*. As you can imagine this makes for very hard to maintain code. Since then the company has begun to enforce a style, and once you are used to it, it seems logical and easy to follow. Now I look at the CircleMUD code, and I can see the same thing, inconsistant styles, and hard to follow code in places.

I was wondering how many other coders follow some sort of standard (obviously not just your own personal one) and if anyone out there (in the appropriate position) enforces a standard on their coders.

When I write code, I aim to leave it maintainable by someone with no previous experience with that code (note THAT CODE! not no experience coding), do others try to do this too, or is "get it working" good enough?

At work, I have a standard to follow which, to my eyes at least, is quite ugly. At home, I follow my own personal standard which is not too different from that used in the Boost libraries. While I'd rather not have to, I think that using two different styles aids in my comprehension of others' code - to help "look past" the notation.

An honourable notion - and one I try to work to. One such idiom I try to keep is "The Code Is The Comment" - sensible naming and layout keeps it as close to English as possible; when that can't be done, add a comment.

However, I think that if you want to leave your program in a state suitable for a maintenance programmer to come along and understand it, you need documentation. Without it, it's only the maintainer's best guess as to the explicit semantics of your work.

Kas.

Yes I do have to apologise for the codong thing, and IF I can find a way to fix it I will.

I find the review idea interesting Tamsyn, and I think used in combination with a document setting out the standards as mentioned by Lodes should end up with consistent and maintainable code. We already have a basic review system in place but a more indepth one would be better. I originaly proposed the or coding standards, but it seemed people did not actually read them (boring I know, but...) let alone follow them.

Has anyone else run up against a prima donna coder (or indeed in general) before, are they as irritating for others as for me?

Dealt with them, am one, yeah. We're all pains in the ass, but occasionally (and happily) some of us end up creating legible, maintainable code that can be used without too much screaming and cussing.

If you're looking for a more structured way of developing your code, the above comments are ones I'd never thought of before, and I have to say they're pretty good ideas. I'm more of a free-form chaotic coder, and most of the people I've worked with like it as fragmented and crazy as possible; probaby why we work together.

But yeah, prima donna programmers in general are a serious pain in the ass. On the other hand, occasionally they have the skills to back up the attitude, and with those you can usually find a happy middle ground; if they're smart enough to be useful, they might just be smart enough to be rational as well.

-Visko