On 05/03/17 18:45, Waldek Hebisch wrote:
I worked with various code and IME it is much easier to work
with generous whitspace. When lines are getting to long just
break them up. One should try to make code simpler and
smaller, but squeezing more code in small space is counterproductive.
It not a big issue for me, I can go along with whatever you prefer, I
just find it easier to work out what a function does if it all fits in
one screen so I don't have to keep scrolling.
Perhaps functions should also be broken up into smaller functions if
they are over a certain size?
Anyway here are my views on such issues in case it might help to codify
things.
Martin B
FriCAS SPAD Style Guide
------------------
The rules on these things seem to evolve over time but I have not seen
them written down in one place. So here is my attempt to do so - along
with my views and questions which may be controversial.
Regardless of whats decided, it might be helpful to have it written down
in one place where it might be seen by potential programmers.
Whitespace around punctuation
-----------------------------
':' space before and after. (I prefer not)
',' space after (but not before). (I prefer not)
'+' spaces optional for most arithmetic infix operations
'-' no space after for unary operations
Maximum Line Length
-------------------
No firm rule but about 70 characters unless that causes problems?
I think this is to make it easier to work with files, for instance
merging with kdiff3.
Block Indentation
-----------------
4 characters (no tabs)
Personally I would prefer 2-space indents rather than 4.
The combination of the above 3 rules seems to make line wrapping much
more common. I prefer code to be compact rather than have lots of
whitespace. I find it is much easier to understand a function if it all
fits on my screen at once.
I would therefore prefer not to have unnecessary whitespace added.
Continuation Lines
------------------
I prefer explicit '_' even when not required. This makes it clear to the
reader that the line has been wrapped.
Function signature
------------------
I prefer explicit types, that is:
func(a:Integer) : Integer ==
rather than:
func(a) ==
This is because it avoids having to jump between function export and
definition to get all information about it. I like to have all
information all in one place.
Empty list
----------
use []$T rather than empty()$T
=>
--
Which is better:
e := (v > 0 => 1; -1)
vs.
e := if v > 0 then 1 else -1
I find the second much more readable, is it less efficient than the first?
Dangling 'else'
---------------
If there is space then the best option is all on one line:
if .... then .... else ....
Otherwise it should be like this:
if .... then
....
else
....
Or is this a valid option?
if ....
then ....
else ....
elt vs. qelt
------------
I prefer better error messages over speed.
_= vs. "="
----------
When to use:
_=(a : %, b : %) : Boolean ==
or should I use:
"="(a : %, b : %) : Boolean ==
reverse vs. reverse!
--------------------
Even if it harms performance I would prefer non-mutable option. Surely
it would have to be a very long list for the longer time to be noticeable.
Function size
-------------
One big function or lots of small (local) functions?
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
