Difference: DesignRules (4 vs. 5)

Revision 52005-05-05 - KrisDeVolder

  META TOPICPARENT 
 name="WebHome" 

 Design Rules
- META TOPICPARENT
+ name="WebHome"
  This is only an attempt to provide a definition / vision on what we mean by "design rule". This is not intended to be the final word on it, but rather a working definition open for dicussion.
  This is only an attempt to provide a definition / vision on what we mean by "design rule". This is not intended to be the final word on it, but rather a working definition open for dicussion.
-<
<
+A Design Rule is a (relatively) easily verifiable rule that constrains how code is to be structured.
->
>
+A design rule is a (relatively) easily verifiable rule that says something about how to write code.
 By adhering to a design rule developers trade away some flexibility on how they write and structure code
-<
<
+in order to make it easier to manually or automatically verify important properties of their software.
->
>
+in order to make it easier to manually or automatically verify important properties.
-<
<
+A design rule is not the same as the actual property one is seaking to guarantee (let's call this the interesting property) but can actually be a weaker or stronger property than the interesting property. The property specified by the design rule is a structural property of their code which developer chose to adopt because it:
->
>
+A design rule is not the same as the actual property one is seaking to guarantee (let's call this the interesting property) but can actually be a weaker or stronger property than the interesting property. The property specified by the design rule is a more structural property which developer would chose to adopt because:
-<
<
+ Is easier to verify (manually or automatically) than the interesting property.
  The fact that the desing-rule property holds boosts the developer's confidence in that the interesting property holds.
  It makes the code easier to read and understand (because it makes the interesting property more obvious and easier to verify).
->
>
+ The design rule is easier to verify (manually or automatically) than the interesting property.
  The fact that the desing-rule property holds boosts the developer's confidence that the interesting property holds.
  Adherence to the design rule makes the code easier to read and understand (because it makes the interesting property more obvious and easier to verify).
-<
<
+For example, let's consider the opening and closing of files. An interesting property we may wish to ensure ourselves of as developers is that:
->
>
+For example, let's consider the opening and closing of files. The interesting property we may wish to ensure ourselves of as developers is that:
-<
<
+ All files that are opened are always eventually closed.
->
>
+ All files that are opened are eventually closed.
-<
<
+This property is potentially very hard to verify. However, it becomes easier to verify
if the following design rule is followed:
->
>
+We do not call the above property a design rule. It rather describes a behavioral property but does not say anything about how we ensure that the property holds. A design rule is more specific in that it says something about the specific code structure one adopts so that it becomes feasible to reason about and ensure that this behavioral property holds.

The behavioral property itself is potentially very hard to verify. This is because there all kinds of ways in which files can be opened and eventually closed. Without knowing the intended design structure a developer has in mind to ensure that a particular file is effectively guaranteed to be closed, it is unclear how to limit the scope of an analysis to verify the property.

However, the property becomes easier to verify if the following design rule is followed:
  Files that are opened by a method should be closed before exiting the method.
-<
<
+By adopting this desing rule the developer agrees to always open and close file in manner similar
to the following idiom:
->
>
+By adopting this desing rule the developer agrees to open and close file in following
something like the following idiom:
      void operateOnFile(String filename) {
 rule may need to be extended to allow for exceptions. For example, we could ammend the rule to allow
open files to be stored in instance variables of certain objects. For these more complex cases we may then chose to adopt other, perhaps more application specific design rules to gain confidence that those files are also not left accidentally open.
->
>
+-- KrisDeVolder - 05 May 2005

View topic | History: r5 < r4 < r3 < r2 | More topic actions...