51–60 of 155 posts
Earlier quoted context omitted.
Sadly quality is highly disregarded in our field. I dream of the day when not making use of contracts, static analysis and type based programming is seen as quality smell and not something that only a few are allowed to make use of.
Type based programming does not quite work in weakly typed languages.
Earlier quoted context omitted.
Type based programming does not quite work in weakly typed languages.
Even in C you can e.g. use singleton structs to distinguish different semantic types.
It looks to me as though the recommendation that RankRed has titled "Rule No. 5 — Low Assertion Density" would be better described as "High Assertion Density" — the recommendation is for a minimum of two assertions per function (and functions are supposed to be short per rule 4). The recommendations look good to me and (with one caveat) correspond to rules that I apply when writing C code with a high reliability requ…
Assertions in code cut both ways. Sometimes they can be great; telling you exactly which assumed invariant is violated. However, that doesn't tell you where or how the invariant was violated. Sometimes assertions are just crutches for lazy programming. Instead of handling of a very valid (corner) case, some people just assert that it doesn't happen. Lo and behold, years later, it does happen. And those years later, t…
If your point is just that the rule could be applied mechanically and without thinking and that would be bad, then that's true, but it applies to everything, not just to the rule about assertions. Someone could apply the "keep functions definitions below 60 lines" rule in a perverse way, by splitting every long function definition at an arbitrary point in the first 60 lines and tail-calling a continuation. It doesn't mean the rule isn't a good one.
Earlier quoted context omitted.
Assertions in code cut both ways. Sometimes they can be great; telling you exactly which assumed invariant is violated. However, that doesn't tell you where or how the invariant was violated. Sometimes assertions are just crutches for lazy programming. Instead of handling of a very valid (corner) case, some people just assert that it doesn't happen. Lo and behold, years later, it does happen. And those years later, t…
Obviously a recommendation to have a high assertion density does not mean "shotgun-spraying assertions in the code". If your point is just that the rule could be applied mechanically and without thinking and that would be bad, then that's true, but it applies to everything, not just to the rule about assertions. Someone could apply the "keep functions definitions below 60 lines" rule in a perverse way, by splitting e…
Wouldn't it be better if we could create programs that were correct by construction (and thus needed no assertions)?
- Well... why C？ If ｃｏｒｒｅｃｔｎｅｓｓ ｉｓ ｓｏ ｉｍｐｏｒｔａｎｔ．．． ｓｕｒｅｌｙ ｔｈｅｒｅ ａｒｅ ｂｅｔｔｅｒ ｌａｎｇｕａｇｅｓ ｔｈａｎ Ｃ － not only better type systems, but also theorem proving and other fancy modern features. It doesn't even have to be garbage collected.
－ ａｔ ｔｈｅ ｖｅｒｙ ｌｅａｓｔ ａｒｅ ｔｈｅｙ ｕｓｉｎｇ ｌａｎｇｕａｇｅ ｅｘｔｅｎｓｉｏｎｓ？ ｅｖｅｎ ｇｃｃ ｐｒｉｍｉｔｖｅｓ ｗｏｕｌｄ ｈｅｌｐ！
If we're talking about high reliability code, one thing claimed about Haskell, is "if it compiles, it has no bugs". How close is it to the truth ? And how close are we to having that kind of capability for real-time programming(even assuming we're willing to forsake protability, community, and maximum efficiency to some extent ) ?
- What tools do they use for error checking/linting? - Well... why C？ If ｃｏｒｒｅｃｔｎｅｓｓ ｉｓ ｓｏ ｉｍｐｏｒｔａｎｔ．．． ｓｕｒｅｌｙ ｔｈｅｒｅ ａｒｅ ｂｅｔｔｅｒ ｌａｎｇｕａｇｅｓ ｔｈａｎ Ｃ － not only better type systems, but also theorem proving and other fancy modern features. It doesn't even have to be garbage collected. － ａｔ ｔｈｅ ｖｅｒｙ ｌｅａｓｔ ａｒｅ ｔｈｅｙ ｕｓｉｎｇ ｌａｎｇｕａｇｅ ｅｘｔｅｎｓｉｏｎｓ？ ｅｖｅｎ ｇｃｃ ｐｒｉｍｉｔｖｅｓ ｗｏｕｌｄ ｈｅｌｐ！
Earlier quoted context omitted.
Obviously a recommendation to have a high assertion density does not mean "shotgun-spraying assertions in the code". If your point is just that the rule could be applied mechanically and without thinking and that would be bad, then that's true, but it applies to everything, not just to the rule about assertions. Someone could apply the "keep functions definitions below 60 lines" rule in a perverse way, by splitting e…
In my experience that what's will happen in practice, especially when there is a specific metric attached. Doubly so once there is a mechanically enforced required amount of assertions. Wouldn't it be better if we could create programs that were correct by construction (and thus needed no assertions)?
It is a shame when that happens, but when it does, it's not the fault of the rules, it's the fault of the organizational culture. The rules would still be valuable if you used them thoughtfully and with the aim of improving the reliability of the product, not gaming some management system.
How does that fixed upper bound on loops work? If there's an array of dynamic size that needs to be looped over, how do you do that?
#define MAX_NUM_OBJS 100 for(int i = 0; i Combined with the no dynamic allocation rule, you can guarantee that the number of elements in the array must be less than some maximum since you have limited dedicated space for storing them.
Say you have a list of visible satellites, and the number of them can change as they go in/out of view. There's never more than 100, but sometimes there's 50 and sometimes 60.
I supposed you could have an object with an INVALID flag, which the loop can use in its logic?