OSDev.org

Hello everybody!
I would like to know how many of you, from the people who write in clear C, follow standards? I mean not using // as comments, declaring variable only in the beginning of the block, and etc?
How do you think, follow ANSI standards considered as "old fashion"?
I always try to declare variable in the beginning of the block, and try to follow the standards as much as I can, but I discovered that GCC don't pay attention to, and while I tried to compile my code on MVC, I got dozed of errors, and it was annoying to fix them.

So do you follow/trying to follow the standards?

(And no, its not a spam, I really want to know)

skwo wrote:So do you follow/trying to follow the standards?

Absolutely.

I consider self-discipline one of the core talents a good engineer is required to have. Actually, sticking to "the rules" religiously is what seperates the programmer from the hacker (in the derisive meaning of the word). Sure you can trial & error until something works, but in the end what you have is not a C/C++ programm, but "something that happens to work in this version of GCC" (until you try to compile with that warning enabled...).

I've had to deal with bad, non-portable code too often, in my professional life, to let it slip. Not following standards - or worse, not even knowing about them - is negligence.

I try to follow C99. I agree with you both: if there is a standard, and it's a reasonable one, follow it best you can.

The standards make things easier to read. Its good practice to follow it. I kind of feel like you have to try in order to program in a different way because the standard seems naturally organized

Generally, I disagree with the above. I am an inventor, not an engineer. I scoff at engineers. If you always follow the standards, you will never ever discover a significantly better way of doing anything. I find that strict adherence to "the rules" will, in fact, often add unneccessary complexity to code and make it less readable. Not following all the rules is also extremely helpful during development of code. For example, using // for comments EVERYWHERE, and then still being able to comment out large sections of code using /* */ effortlessly is mighty handy.

The reason the shortcuts exist in the first place is that programmers who are willing to experiment a little have found those shortcuts to be a significant improvement to the code, in some way. Religiously avoiding them is pedantic and shortsighted.

Hi,
I partially agree with the above posters . I do not completely agree with bewing or Solar . Adherence to strict standards all the time hampers imagination , but total negligence to standards is not very good as well . I am a great believer in the protyping methdology . The idea is to write a prototype and then peforom unit tests . Unit testing will provide you more insight whether your design is good or bad . I would iteratively repeat the above process till I am satisfied . Then finally a protype which suits all my goals is obtained . A bad practice would be to refactor this prototype to build the final product . A prototype is after all a prototype and it should be scrapped off . Then I can build a final product that meets the standards and quality requirements . This is basically what people call "explorative programming " and you learn as you program .There is a method in my madness .

The most irritating thing which find with most of the os dev tutorials is that they start with a bootloader , when they should start with a filesytem or a shell which can unit tested with easily by writing stubs . Please take a look at this article it is quite informative: http://www.ibm.com/developerworks/libra ... ktest.html .Then finally we should then go deeper from the user space . I may write my own set of tutorials some time , but i have no time now .

Finally , I want to warn you that I am an idoit and my comments may not make any sense .

Regards
Shrek

bewing wrote:Generally, I disagree with the above. I am an inventor, not an engineer. I scoff at engineers.

...

No, I won't go there.

But I'll poke at the rest. (Sorry, this will get warm.)

If you always follow the standards, you will never ever discover a significantly better way of doing anything.

In a programming language, there are only two ways to do anything: The correct one, and all the others.

(Next paragraph goes to Shrek, too.)

We're not talking at what you implement. Fire away, be imaginative, find new techniques. But if you're writing C, then write C. There's no language called "GCC". Code not adhering to the standard is broken.

Edit: That might be in excusably little ways, or in blatantly obvious ones, but the code is still, and clearly, wrong. There is nothing you can do with broken code which you could not do with correct code as well. I challenge you to show me otherwise.

I find that strict adherence to "the rules" will, in fact, often add unneccessary complexity to code and make it less readable.

You mean, less readable for you...

Not following all the rules is also extremely helpful during development of code. For example, using // for comments EVERYWHERE, and then still being able to comment out large sections of code using /* */ effortlessly is mighty handy.

• C99 does support //.
• If you want to support C89, use #if 0 / #endif (which even nests correctly).

That is exactly what I meant with "negligence". Because you scoff at the standard and don't think twice about taking your shortcut, you're not as good in what you do as you could be.

The reason the shortcuts exist in the first place is that programmers who are willing to experiment a little have found those shortcuts to be a significant improvement to the code, in some way.

And because they were good, they were accepted into the standard (like // was). Until it's in the standard, using it limits you to a specific toolchain, probably even a specific version of that toolchain. Toolchains change, and suddenly your code doesn't work anymore. (It's not the toolchain, it's your code, which was broken all the time, only now the toolchain doesn't let you take that shortcut anymore.)

If enough coders are negligent enough, such an illegal shortcut becomes a "historic legacy", and time, effort, and money is wasted because toolchains have to maintain compatibility with the bad practices of yesterday. Time, effort, and money that could have been invested in improving those toolchains instead.

Not even talking about the pains you have brought onto those who had to think around your shortcuts. Chances are, a smart piece of non-standard code that saved you a minute in coding will cost others many times as much in productivity as they have to think around or refactor your shortcut.

Edit: Reading quok below, I realize I should say that I am talking language standards here. Like, C, C++. I wouldn't touch POSIX with a stick, for example - there is an example of a "post-mortem" standard that doesn't make sense to follow to the letter.

I'm going to have to agree with pretty much everyone that's posted before me. Standards are there for a reason. My kernel project uses C99 almost exclusively. I stay away from 'char' and 'int' as much as I possibly can. uint32_t may be more to type, but it's more clear, and it definitely forces me to think about if I REALLY need all 32 bits just to store a -1, 0, 1, or something like that. I try to use _Bool as much as I can as well.

My feeling is that if a standard exists that covers what you want to do, and you expect your code to be portable, then use the standard. For instance, a kernel doesn't necessarily HAVE to follow a standard. Maybe you don't want your kernel to be POSIX compliant. A C library, though, MUST be compliant with the C standards (yes, all of them). That isn't to say you can't add additional functions to the library (just look at glibc for an example).

However, I do also agree a lot with Bewing. If all you ever do is follow standards, then you are really limiting yourself. There's many standards out there that just don't make sense, are badly written, or can't be implemented in a sane matter at all. Portions of the POSIX standard are, IMO, in this category. Luckily you don't have to implement ALL of the POSIX standards, as the POSIX committee was smart enough to have such things as feature test macros.

One of the first things I do whenever I start a new code project is write a list of "Coding Style Guidelines." Everyone has a different style, and mixing all those styles together results in very very messy and unreadable code, even if all the developers in the project are gods among men. Forcing a consistent style in the code base goes a long way toward helping code readability.

Hi,

The most irritating thing which find with most of the os dev tutorials is that they start with a bootloader , when they should start with a filesytem or a shell which can unit tested with easily by writing stubs . Please take a look at this article it is quite informative: http://www.ibm.com/developerworks/libra ... ktest.html .Then finally we should then go deeper from the user space . I may write my own set of tutorials some time , but i have no time now .

I personally don't think unit tests are a useful form of testing, especially for OS development where the modules are so dependent. Getting a unit test set up with a simulated environment is a lot of effort and, again, you have to test the correctness of your simulation. Does that call for a unit test too?

I think that testing the system as a whole (perhaps probing parts of it etc) is a better way to do things.

James

JamesM wrote:Hi,

The most irritating thing which find with most of the os dev tutorials is that they start with a bootloader , when they should start with a filesytem or a shell which can unit tested with easily by writing stubs . Please take a look at this article it is quite informative: http://www.ibm.com/developerworks/libra ... ktest.html .Then finally we should then go deeper from the user space . I may write my own set of tutorials some time , but i have no time now .

I personally don't think unit tests are a useful form of testing, especially for OS development where the modules are so dependent. Getting a unit test set up with a simulated environment is a lot of effort and, again, you have to test the correctness of your simulation. Does that call for a unit test too?

I think that testing the system as a whole (perhaps probing parts of it etc) is a better way to do things.

James

For the most part, I agree with this as well. However, unit tests are still useful for some things. For instance, you could save a known memory map to a file and use that as input to test your routines for sorting and sanitizing memory maps. And of course, there's always using things like LD_PRELOAD for testing malloc() implementations, and things like that. But many many parts of a kernel are hard to unit test, at least until you've got some decent functionality in there.

I see many opinions here
Well I rewrote my code to follow standards (dam bit-fields in structure unsupported >.< )
Anyway I think that we should follow standards as they create not just for fun, if one is writing in C so he must write in C and not "something that tends to be C".

(dam bit-fields in structure unsupported >.< )

Bitfields are incredibly useful. I wouldn't abandon them just for the sake of standards-compliance (which standard doesn't allow them, OOI?)

Solar wrote: In a programming language, there are only two ways to do anything: The correct one, and all the others.

No, there are a million ways of doing everything. 99.9% of it comes under the header of "individual taste". What some committee considers "wrong" is just a matter of the personal tastes of a majority of the people who happened to muscle their way onto the committee. To follow blindly is to be a sheep.

Strictly follow K&R standards if you want to write REAL C.

And because they were good, they were accepted into the standard (like // was).

Until enough programmers break the rules, no change ever gets added to the standard. You argument is circular, and therefore irrational.

Strictly follow K&R standards if you want to write REAL C.

K&R is a style, not a standard. And it's horrendous.

Until enough programmers break the rules, no change ever gets added to the standard. You argument is circular, and therefore irrational.

And until enough people go out and kill people, the law will never be changed to allow murder.

You can break the standard if there is a good reason for doing so; just being lazy isn't a good reason.