A list for the developers of CellML tools

Text archives Help


[cellml-dev] Code style suggestion


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] Code style suggestion
  • Date: Thu, 01 Nov 2007 10:38:06 +1300

Randal Britten wrote:
> Hi all
>
> I would like to suggest that we change our current code style
> standard. I think that abbreviations should be avoided for identifier
> names. Abbreviations remained popular because they saved some typing,
> but modern IDE's have autocompletion and similar features.
>
> Not sure if Emacs supports autocompletion or not. I know this will be
> harder if Emacs does not support autocompletion,
emacs has had a feature called dabbrev (dynamic abbreviations) since
1991, which is roughly equivalent to what other editors have later
called autocompletion.
> but I don't think we
> should compromise our coding style for the sake of a particular editor.
>

I don't think that we should automatically assume that it is bad coding
style to use abbreviations. I think that this sort of decision should be
made on a case-by-case basis.

Brevity of code is always going to be a trade-off - very long code is
hard to read because:
1) you end up with long, hard to read, lines, or wrap a small amount
of actual code over a large number of lines, again making it hard
to read.
2) it becomes harder to focus on the algorithm because of all the
unnecessary details (the whole point of mathematics is to hide the
details of the problem and solve the problem in the abstract, and
similar concerns often transfer well to code).

However, overly succinct code can also be hard to read.

I think that things like using traditional variable names like i and j
for loop indices is sensible and improves readability, and often also
makes the code more abstract and re-usable (of course, such variables
should ideally be short-lived local variables).

Longer lived variables (globals, class members etc...) benefit more from
having a more verbose name. Reasonable (unambiguous) abbreviations are
not a problem, especially if the abbreviation is already common outside
the code (for example, I find 'spec' easier to read in the graph code
than 'specification' would be, and it is reasonably clear in the context
what an object called spec stores).

Best regards,
Andrew

> Regards,
> Randall
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-tools-developers
>





Archive powered by MHonArc 2.6.18.

Top of page