Re: Should we follow standards? Do you follow?
Posted: Fri May 01, 2009 12:02 pm
The best C++ code can be faster than the best C code, with a compiler capable of optimizing both equally well. Of course, C++ is a huge language, so writing the best code possible is beyond most programmer's capabilities [Mine included, though I think by now I have 95% of the language covered]
As for standards: If you have ever done any form of engineering, you will realize that within each engineering subfield field there:
1) Standards which you will find invaluable, and
2) Guidelines, which you will follow because they are the right thing to do.
For example, from electrical engineering:
The standard chip packages are invaluable. They make chips cheaper, because companies can buy standard packages. They make design easier, because you don't have to draw up the package yourself, but use one your PCB design software has, and they are in general designed by people who know what they're doing with regards to the hundreds of parameters that affect signals passing through a package.
Then there are the guidelines, such as sprinkling capacitors liberally all over the PCB on the power rails. If you don't, it might work, if it's low frequency (Less than about 10MHz), but look at it wrong and it will do something funny. A general rule is 1 per chip for small, low complexity chips; more complex chips normally have multiple power pins, and the count can hit 8 or more for some really high power, high speed chips. Guidelines and rules are incredibly important when you start hitting high speeds with wavelengths of less than the length of a PCB trace, or close to it.
Of course, that doesn't mean they should be blindly followed, good reasons exist. For example, it's entirely valid for Intel and AMD to package their chips in custom packages because they're not designed to be soldered down to a board. They're not desigend for use by electrical engineers; theyre designed for use by consumers. They should design a new socket every time the electrical interface is made incompatible, else someone is going to be very upset. However, as you may have got from that, exceptions are for exceptional circumstances.
And this also applies in the field of software engineering. And Bewing should know that inventors are engineers too. Because if you don't know the rules and guidelines, you end up reinventing them, and inevitably come up with the same conclusion, but it takes longer, and is something only you can understand.
Programming, in general, has a lot in common with Engineering, and can learn a lot from a field that is many times it's elder. Not blindly, of course; some aspects do not apply. But many do.
And I say this all as someone who started in the field of software.
As for standards: If you have ever done any form of engineering, you will realize that within each engineering subfield field there:
1) Standards which you will find invaluable, and
2) Guidelines, which you will follow because they are the right thing to do.
For example, from electrical engineering:
The standard chip packages are invaluable. They make chips cheaper, because companies can buy standard packages. They make design easier, because you don't have to draw up the package yourself, but use one your PCB design software has, and they are in general designed by people who know what they're doing with regards to the hundreds of parameters that affect signals passing through a package.
Then there are the guidelines, such as sprinkling capacitors liberally all over the PCB on the power rails. If you don't, it might work, if it's low frequency (Less than about 10MHz), but look at it wrong and it will do something funny. A general rule is 1 per chip for small, low complexity chips; more complex chips normally have multiple power pins, and the count can hit 8 or more for some really high power, high speed chips. Guidelines and rules are incredibly important when you start hitting high speeds with wavelengths of less than the length of a PCB trace, or close to it.
Of course, that doesn't mean they should be blindly followed, good reasons exist. For example, it's entirely valid for Intel and AMD to package their chips in custom packages because they're not designed to be soldered down to a board. They're not desigend for use by electrical engineers; theyre designed for use by consumers. They should design a new socket every time the electrical interface is made incompatible, else someone is going to be very upset. However, as you may have got from that, exceptions are for exceptional circumstances.
And this also applies in the field of software engineering. And Bewing should know that inventors are engineers too. Because if you don't know the rules and guidelines, you end up reinventing them, and inevitably come up with the same conclusion, but it takes longer, and is something only you can understand.
Programming, in general, has a lot in common with Engineering, and can learn a lot from a field that is many times it's elder. Not blindly, of course; some aspects do not apply. But many do.
And I say this all as someone who started in the field of software.
