Journal Articles
Browse in : |
All
> Journals
> CVu
> 124
(22)
All > Journal Columns > LettersEditor (132) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: The Wall
Author: Administrator
Date: 08 July 2000 13:15:38 +01:00 or Sat, 08 July 2000 13:15:38 +01:00
Summary:
Body:
Dear Pete,
Curly Braces
Thank you for your very interesting article on professional programming and code layout in particular. I enjoyed it and look forward to reading your future articles. You mentioned you would be interested in hearing from people so I thought I would put my own views on coding guidelines forward.
Although I have worked for companies who had coding guidelines I have never worked for a company that either enforced them or where the guidelines really were part of the culture and were followed by all. (I have been a programmer in the PC industry since 1983 at such companies as the now defunct Digital Research.) In my experience a company will periodically appoint (or allow) an individual or small group to go away and produce a style document which is to be adopted by all programmers. While writing the document the group may request suggestions from all, or when it is released they may request comments, which helps give individual programmers not directly involved in defining the style a sense of ownership. Anyway, the document is written, distributed and ignored. Some people might read it. Some might try, for a while, to adopt the style. However, in the heat of battle (with deadlines) it goes out the window. I suppose management could really throw its weight behind the document and turn guidelines into law, make it a sackable offence to put your curly braces in the wrong place, employ a style police to monitor people's work, encourage programmers to grass up their colleagues. However, they have not done that at places I have worked. Maybe they could change the culture: get all their programmers to believe in their hearts that it is important that all Boolean variables start with a small b. But they haven't done that at places I've worked either.
Where I have worked the problem domain has always been the priority. What I mean is that management valued people who understood the technical details necessary to produce a working solution or product for a given business model, e.g. an OS for a PC. They got some extremely able people together and they wrote the code. I do not think they gave a stuff what the code looked like so long as it worked pretty well in a given time-frame. Of course, I am talking about "commercial-grade" software here, i.e. the buggy stuff that people refuse to buy version 1.0 of.
One company I have worked for had the following statement in its proposed style guide:
"In the same way that a wolf dressed in sheep's clothing will still eat you, wrong code that follows all the style guidelines in the world is still wrong. In other words, style is no substitute for understanding. However, the clarity with which C++ code is written has an effect on the ease and speed with which a person can grasp its function. This clarity is important to [company name] and you are encouraged and trusted to write readable code. Clarity is more than where you put your curly braces..."
Which I think sums up my own views quite well. I think a company should recruit good programmers and then trust them to write good code. If they find there is a problem with the quality of the code being produced they should give their staff every encouragement to improve: give them access to good books on programming practice, send them on training courses, or whatever. Reading back over the above I wonder why I feel so strongly against the imposition of a coding style by an organisation on my own work. I do not think I know why exactly. I think I've made clear my feeling that following a particular style will not necessarily lead to correct - or in any other sense good - code. However, what harm can it do? I enjoy writing programs; I take a certain pride in my work...
I just mean I do my best to do good work, where appropriate, and I care about what I am doing. It is not just a job. I suppose having a style forced on you removes a certain amount of freedom of expression. I think there is also a feeling that my skills (such as they are) are being somehow undermined: any fool can write decent code if they follow these guidelines. I do not fully understand these feelings and I suspect that they reveal that I am actually not very professional. For this reason, I would like to remain...
Anonymous.
Thanks for making the effort to share that with us. I think that your problem may be one that is widespread in the industry. Very often coding guidelines seem to impose entirely arbitrary requirements. Most of us start our programming as individuals and we are often fiercely individualistic. We know that many of the rules would make no difference to the quality of the code that we produce as individuals. However, I think we need to recognise that as soon as more than one person is involved (and that includes the fact that someone else, years hence, may have to maintain our code) we must consider more than just our personal likes and dislikes.
Companies that either do not have, or do not enforce coding standards and guidelines are unprofessional. FG
Notes:
More fields may be available via dynamicdata ..