leonardo

View: Recent Entries. View: Archive. View: Friends. View: Profile. View: Website (My Website). December 19th, 2010 Tags: programming Security: Subject: More Software Engineering & Development Time: 08:45 am

http://leonardo-m.livejournal.com/98451.html



Now the slides of the last lecture too are available:

http://sweng.epfl.ch/schedule/13LayoutandStyle.pdf



At page 9 of the lecture slides #13 it shows a member function that starts like this:

/* Use the insertion sort technique to sort the "data" array in ascending order. This routine assumes that data[ firstElement ] is not the first element in data and that data[ firstElement-1 ] can be accessed. */ public void InsertionSort( int[] data, int firstElement, int lastElement ) { // Replace element at lower boundary with an element guaranteed to be // first in a sorted list. int lowerBoundary = data[ firstElement-1 ] ; data[ firstElement-1 ] = SORT_MIN; ... But my advice is to transform comments into code as much as possible. it's better to convert invariants, constraints, limits, and other semantics present in the comments into code that the compiler/interpreter runs and verifies. Sometimes simple assert() are enough. Beside normal asserts, in D language there are also "static asserts" and "template constraints" that enforce constraints at compile-time, and the pre-conditions, post-conditions and invariants of the Contract Programming. (It's also good to copy as many comments into unit-tests).



Experience seems to show that many assertions are very useful in low level coding too, this quotation is from "Design by Contract (DbC) for Embedded Software" (2009) by Miro Samek:

http://www.netrino.com/node/266

However, because our software was programmed mostly defensively, in absence of errors in the log we didn't know if the "cycler" run was truly successful, or perhaps, the code just wandered around all weekend long silently "taking care" of various problems.



In contrast, every successful test run of code peppered with assertions builds much more confidence in the software. I don't know exactly what the critical density of assertions must be, but at some point the tests stop producing undefined behavior, segmentation faults, or system hangs -- all bugs manifest themselves as assertion failures. This effect of DbC is truly amazing. The integrity checks embodied in assertions prevent the code from "wandering around" and even broken builds don't crash-and-burn but rather end up hitting an assertion Assert failures are better than normal bugs because they give you an idea of what's wrong, and the line number of the assert error is often close to the unknown line number of the actual bug. This helps speed up debugging.



In a language with a more flexible type system you are also sometimes able to encode invariants into types (and if the type system is static such enforcement happens at compile time). As example in the Phobos D standard library there are the structs assertUnique and assertSorted. Languages with more powerful type systems like Haskell, Scala or even ATS allow for more comment semantics to be moved to the type system.



Moving comments into code has some advantages:

- The compiler/interpreter complains if you do something wrong. While comments are silent. This is the biggest advantage.

- The constraints are kept in sync with the changes done to the code, while with time comments may get out of sync (on the other hand unit-tests and constraints are a burden of code that needs to be modified to be kept in sync).

- The constraints must run, so they often can be understood, while comments sometimes are cryptic. If comments are written in a language you really don't know, code becomes much more readable, even when the variables have funny names (generally I suggest to write comments and variable names in English, even in Engrish).



This general rule of converting comments into code is right even for language designers. Someone has said that if you look at the hystory and progress of programming languages, you see that more modern languages allow you to express more and more comments inside the code itself. So it's generally good to invent languages that allow to express as code a growing amount of constraints and semantics that until now was expressed in the textual comments.



C++x0 language design used to have Concepts, Concept Maps and Axioms (



Said all that, in several situations comments are useful. One purpose of a comment is to explain the purpose of a class, function or paragraph of code. Recently I've written some comments about a nice software engineering course:Now the slides of the last lecture too are available:At page 9 of the lecture slides #13 it shows a member function that starts like this:But my advice is to transform comments into code as much as possible. it's better to convert invariants, constraints, limits, and other semantics present in the comments into code that the compiler/interpreter runs and verifies. Sometimes simple assert() are enough. Beside normal asserts, in D language there are also "static asserts" and "template constraints" that enforce constraints at compile-time, and the pre-conditions, post-conditions and invariants of the Contract Programming. (It's also good to copy as many comments into unit-tests).Experience seems to show that many assertions are very useful in low level coding too, this quotation is from "Design by Contract (DbC) for Embedded Software" (2009) by Miro Samek:Assert failures are better than normal bugs because they give you an idea of what's wrong, and the line number of the assert error is often close to the unknown line number of the actual bug. This helps speed up debugging.In a language with a more flexible type system you are also sometimes able to encode invariants into types (and if the type system is static such enforcement happens at compile time). As example in the Phobos D standard library there are the structs assertUnique and assertSorted. Languages with more powerful type systems like Haskell, Scala or even ATS allow for more comment semantics to be moved to the type system.Moving comments into code has some advantages:- The compiler/interpreter complains if you do something wrong. While comments are silent. This is the biggest advantage.- The constraints are kept in sync with the changes done to the code, while with time comments may get out of sync (on the other hand unit-tests and constraints are a burden of code that needs to be modified to be kept in sync).- The constraints must run, so they often can be understood, while comments sometimes are cryptic. If comments are written in a language you really don't know, code becomes much more readable, even when the variables have funny names (generally I suggest to write comments and variable names in English, even in Engrish).This general rule of converting comments into code is right even for language designers. Someone has said that if you look at the hystory and progress of programming languages, you see that more modern languages allow you to express more and more comments inside the code itself. So it's generally good to invent languages that allow to express as code a growing amount of constraints and semantics that until now was expressed in the textual comments.C++x0 language design used to have Concepts, Concept Maps and Axioms ( http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 ), but they were later removed from the draft standard. They are ways to give a full type system to templates and to define some semantic properties of concepts. They are complex to implement and they have several corner cases. This shows an example where the costs of moving some semantics and constraints into the code was too much high (but maybe something similar will be added to a language less complex and more clean than C++). D language has adopted a much simpler and less powerful solution (template constraints) that while not perfect are simple enough to implement and use.Said all that, in several situations comments are useful. One purpose of a comment is to explain the purpose of a class, function or paragraph of code. comments: Leave a comment

leonardo

View: Recent Entries. View: Archive. View: Friends. View: Profile. View: Website (My Website).