Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Big Sassy

Coding Standards in the Workplace

This topic is 5971 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I know there is a decent amount of profesional programmers on these forums so I hope to get a few replies. How does your company handle coding practises in the workplace? Is there a certain way everyone''s code should look? Do they stress Hungarian notation? How about commenting styles? Also, how much does your workplace enforce them? Do you risk getting fired if you don''t comment a function?

Share this post


Link to post
Share on other sites
Advertisement
I''d call our standards semi-hungarian. They love the variable naming conventions but not some of the more weird stuff. They especially love using variable names that mean something, even if they are half a page long. Tabs are important, every job I''ve had requires tabs-as-spaces, with 2 as the indentation and tab value.

Commenting style is not a big deal, but comments themselves are encouraged at my current job. It''s not unusual to find "// touch and die, call me first at Ext ####" types of comments. At Raytheon they were extremely retentive about comment blocks before every single function and at the top of every single file with very stringent formatting requirements, but that''s because they were trying to get level 3 for ISO 9000, so we pretty much gritted our teeth and used the copy/paste hotkeys a lot.

Even at Raytheon you wouldn''t get fired for not commenting a function. You''ll likely get fussed at and told to do it, but not seriously yelled at. The companies I''ve worked at consider coders that are familiar with their (massive) projects to be pretty valuable and they won''t fire us over a few comments. Comment requirements are not even close to being as stringent as they are in a classroom setting, because they more or less expect that anyone reading the code can, well, read code, and unless you''re doing something weird or being bad about what you''re naming your variables you usually won''t need to comment too much.

-fel

Share this post


Link to post
Share on other sites
Actually, even if you''re doing something not-so-weird, it''s always good to add a little comment. Just tonight I came across some code in our 7 year old code base that called a function called "SaveTempGame()" or something similar. This function did just what it said - it saved a copy of the current game into a temp folder. What it did not bother to explain is WHY it did it. Nor did any place that called it. Nor, in fact, did anything anywhere in the codebase. So, while its effects are easy to figure out, its intent isn''t so easy.

And the topic of conventions - if you ever want to see hell, look at a code base that was built by over 40 engineers over 7 years across 5 platforms, most of whom did not have any formal training, and you will quickly understand why coding conventions in a multi-million line code base are very important for maintainability.

And of course, there is zero accountability. In fact, most of the people who wrote some of the older legacy functions aren''t even in the industry anymore, let alone available to explain what the heck they meant by a piece of code - and even if they are, probably couldn''t. It was for this very reason I made a comment to a coworker tonight (one of many 16+ hour days) along the lines of, "The only reason we''re still here tonight is because of the sloppiness / laziness / inability of the people before us."

I also coined the terms "ungineer" and "congrammer".

Ah well. 1am and the build''s almost done.
-scott

Share this post


Link to post
Share on other sites
My last job had a style guide that they expected us to use. It was essentially Hungarian, with a few minor differences. There was no real mandate when it came to commenting style, but they were encouraged. Like fel, I was expected to set VC++ to convert tabs to spaces and use a tab/indent size of 2, so that the code would line up properly for people using other IDEs (such as JOVE, Microsoft C, or Borland C). I don't think that failing to adhere to the standard is something they'd fire you over.

At my current job, if there's a coding standard, I've never heard about it. Looking at our code base, if there is one, it must change every few months

Share this post


Link to post
Share on other sites
We don''t really have an official coding standard because we use so many different languages. My company develops software to manage servers / routers. It collects the information from an agent and presents it on a console. Our agent runs on well over 200 OS / architecture combos, and has about 100 major components that you can plug into said agent and console framework.

There are internal developer websites that offer suggestions on how to format your code, but there''s no single standard or rule and the suggestions aren''t available for all of the languages we use. The format differs between platform and development group by quite a bit.

Share this post


Link to post
Share on other sites
Our company has no formal rules, except every piece of code must be scrutinised and approved by an independent reviewer (someone else in the company) before it can be used in a final product. This is an excellent encouragement to make code clear and friendly, ''cos no one wants their code to fail the review.

Share this post


Link to post
Share on other sites
We have fairly strict coding standars, based on the Ellemtel Rules and Recommendations. Formatting, commenting, naming, and language usage are all expected to conform to the standard. Failing to do so won''t get you fired, but it will make coworkers and supervisors rather unhappy.

Share this post


Link to post
Share on other sites
A big company I was working at before I moved here had some pretty decent code standards. The software was so immense there had to be some. Stuff like prefixes for classes, good variable names with correct spellings (no "nbrOfPpl"). Pretty much just followed what Code Complete talked about. We had to do regular code reviews in which fellow employees/friends/enemies got to make fun of your code while it was shown on the wall. When people could not figure out what was going on at first glance, it razed havoc, thus making all of us make really nice readable code. Think your code is well written and readable? Then you have either had a similar experience, or living in a fantasy land.

Through my contract jobs, I have never had a standard forced on me, and just kept the one from the last job. I think it is important to keep to the same standard at least in your own code if there is not a company policy. Nothing like having code where the first letter of variable is lowercase for some members, and upper for the rest.

Share this post


Link to post
Share on other sites
Where I work, all the source code is available to the customer (as they may want to maintain it after we have left). So Our comments and naming conventions are customer specific.

As an aside to this, I thought that it would make people more likely to play but we work in a rapidly changing field and if they tinker they lose their warranties so the worst we get is we think theres a bug here, and an explanation of the code which actually helps a great deal. (Doesn''t stop us having to fix it though)

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!