The siliconBrain tool and siliconBrain applications are installed outside the normal bin dir's. Also their libs are excluded from the others. So names do not have a prefix. That is, if you execute someCommand while being in a siliconBrain development environment, siliconBrain's version of someCommand will be executed. Outside the siliconBrain context the commands are not visible. In that way we do not pollute the command namespace of a computer.
Other reasons not to use prefixes have to be long to be unique. It is very unintuitive to have prefixes before every command. It is a burden to type them, and even more if there are long prefixes.
One intention of the organization of siliconBrain projects is, to be able to run several versions in parallel on one computer. Here prefixes to command names would not help. And so we have had to look for another solution. This solution then also gives the possibility to work without prefixes.
Sometimes there are exceptions. When there are commands or variables,
which have a relatively common name, such as “packageName” or “install”, which in
turn probably will interfere with operating system commands, or
commands from other products, the are prefixed by
“siliconBrain”. This is especially true for operating system
environment variables, which are export'ed.
So the installation procedure of siliconBrain is siliconBrainInstall.
Abbreviations are easy to type but not so easy to remember. And even more heavy to read and understand. In a world of command line completion and similar facilities of editors, to be short is no longer an advantage. So we use long names, describing the objects the name.
Very common abbreviations like cvs, html or ftp are exceptions, of course. They in the meantime have the status of words rather then abbreviations. They are treated as words.
This is true for directory names as well. So instead of tmp we name it temporary.
A directory containing configuration should not be named etc. It is named instead configuration. A directory containing executable programs is not named binary, as would be the not abbreviated bin, but is called programs. A bash script for example is not a binary file. It is pure readable text. Nevertheless it is a program.
Normally objects are not named according to their type. For example an
account number is not called number but account.
An implication for options for commands is, that we always use long-format options like rm --force. All commands we define for siliconBrain or a siliconBrain project have at least also a long format. In all scripts or wherever we call a command we use the long-format options. Maybe for some options there is a short alternative like rm -f. But this form is just for humans, who like to type a command intercativly into a command line. When an option has its equivalent in a configuration file, we will use long describing word as well.
File extensions like c in myProgram.c are used to
specify how to handle the file during the make process. The
rightmost extension is also used to indicate the editor style to
use. If their are different type of handling for the same language
used, second level extensions are used: There are two different kind
of C-sources: those which contain a main and will be linked to
a command, and those which are designed to be part of a library. The
first get the extension .main.c the second .lib.c.
Executable programs residing in programs never have an extension. It should be completely transparent (invisible) for the user of a program, in which language it is written, whether it is C, awk or bash.
For bash-programs that means: in the source tree they do have the extension .bash. Doing so, make knows what to do with it. Compiling them means to copy them to the directory programs without any extension.