SmartEiffel and ESE

From ESEwiki

The SmartEiffel philosophy can be summarized in a few rules. Except when specified otherwise, the same rules apply to ESE.

The way of thinking

SmartEiffel is all about type tightness. Any entity must be correctly typed. ANY is not a good type.

Typed coercion should be really rare, and when inevitable downcasting must be obvious (i.e. no "is-a" test should be used except in contracts).

For example, the fact that there is no boxing and that sometimes types cannot automatically be assigned (esp. when expanded) imposes some coding patterns. Internals, and the Eiffel Data Connection API, are examples to be followed.

The way of coding

The code is never locally compact. But global compactness is a rule.

SmartEiffel libraries require a tight memory management (because tools may be compiled with the -no_gc flag). That's the one rule I relax for ESE, but all the same most strings should be once, and STRING's + operator is forbidden (i.e. the rule is relaxed but that's no reason to create too many short-lived objects).

Emacs and vim both have syntax templates included in the misc directory of SmartEiffel, which should be used for ESE. If you don't use either emacs or vim, tabs are three-character long and are compulsory for code indenting. The text width is set to 110~characters. Feature definitions arguments have the opening parenthesis preceded by a white space, while feature calls have the opening parenthesis immediately following the feature name (no space)^[1]. The pretty tool is useful too. See the SmartEiffel source code for examples of formatting.

The indexing keyword is never used. Heading comments are good enough for that purpose^[2].

Feature clauses must always have an explicit client list. Also NONE is not a valid class. That's what the following table shows:

SmartEiffel tools

Code documenting is done with the eiffeldoc tool. One of the very useful uses is the mediawiki-like syntax of feature comments. Also, class names (in upper case) and feature names (between simple quotes) are recognized, that's very useful for "see also" tags.

Testing is done with the eiffeltest tool. (More about that later; the tools is still being designed by the SmartEiffel core team.)

Notes

1. ↑ Rationale: that's very useful when using text search tools.
2. ↑ I'm talking of the ESE code, not code users would write using ESE. Furthermore, maybe some tools will be designed to use the indexing facility as some kind of meta-data annotation. Just wildly throwing ideas here.