Posted on Nov 5, 2013 14:35PM

About the Code

This version of WordBash lacks the Admin code and some features.

WordBash is Weird

If you have looked at the source code you are probably shaking your head in bewilderment as WordBash is not written an any sort of "standard" style. I do some things that nobody else does or would do; but there is a reason to my madness. I may appear to be trying to obfuscate the code; on the contrary, it should become clear.

The file readme.txt explains the variable naming convention I chose, and over time things have gotten a bit more complicated than I imply here (it's essentially this post updated).

WordBash is written in a unique style of my own making because I was working with only the Bash man page at the time (it provides no examples), and I made things up to suit myself—and I created a stringent, self-documenting naming convention. I started with an Object Oriented approach suitable for change (yes, OO in Bash). This is described below.

Everything is designed with a minimalist's perspective—everything is minimal in size and scale: variable names, file names, file length, function length... everything.

File Names

The main code consists of one CGI script, a "configuration" source file, several "library" source files and a few HTML files. The HTML files are in cont/. The library files are in libs/. All the site's data are in meta/ (in a fairly complex—for now—hierarchy).

The CGI file is wordbash.cgi. All other source files have a .sh extension. The main configuration file is B.sh. Library files are a single uppercase letter, with each file's letter related it's use. The library files are libs/C.sh for comments, libs/P.sh for posts, etc. There is also a supplemental configuration file, cf.sh, which expands some data defined in B.sh.

Variable Names

I chose a very specific naming convention. Globals are of four groups: CGI, Config, Library and Template.

Area	Used	Name
CGI	in the `.cgi` code	3 or 4 letters, whole word (GET/POST data)
Config	anywhere	2 letters beginning with the letter 'B'
Library	in a library	2 letters beginning with the letter of the library
Template	anywhere	"word" variables such as 'body', 'title'

In addition there are a few two letter variables beginning with 'r' and ending with a library letter for library function exit status; several web template only variables starting with 'site'; and a few generic functions beginning with 'b'. Temporary variables are always a single letter. Local variables can be anything. Cookie variables (there is one) begin with an underscore.

Constants

Variables used as constants are four uppercase letters beginning with the library which it is defined for.

In other languages, such as PHP, global data is generally avoided. But with Bash, global data is a benefit and not a problem. Overuse of subhells to "pass" data around adversely effects Bash performance for CGI use.

Libraries

A library interface is an Object Oriented function named by the same uppercase letter, each taking one or more arguments: a "command letter" and optional data. Examples:

bash code

C l

C a "$data"

P t "$tag"

P p $n

The command letters are abbreviations for actions: "list", "add", "tag", "print". This is equivalent to, and no different than:

PHP code $Comments->list();
$Comments->add($data);
$Posts->tag($tag);
$Posts->print($n);

A library may have it's own "internal" functions. These functions are named with two lowercase letters, with the first letter the same as the library name, the second indicative the function's purpose. These functions may actually do the "work" of the library, however, these functions are not called directly, only a library's "main" entry point is ever called.

Library global variable names generally follow the command name: $Cn for C n for example.

Code Comments

There are no code comments. (Other than a few functions being named.) This is not to hide anything (i.e. they have not been removed for they were never written). While writing the code I wanted to focus on writing code not comments. (The thought of commenting for other people did not occur to me as I was unsure if this would work.) If the code is not understandable (depending on your Bash fluency) then I am doing something wrong.

Self-documenting conventions along with documentation such as this makes for better code in my opinion.

To Bash Coders

I learned Bash in a vacuum, with the bash manual as my sole guide at first. Therefore, two things about my code: I probably do not do what most Bash programmers do; I probably do what most Bash programmers would not do.

There are some inconsistencies around the use of $?, and a few other things of that nature. I chose to use the [[ conditional command overall instead of inter-mixing with test for consistency. Strings in conditionals are not double quoted if they are whole words or numbers. Some variables and functions share the same name—I find this to not be a problem as their use are not the same.

Summary

Whatever one thinks about my coding style or my implementation (which is changing): this is the basis for a working WordPress clone in 1,300 lines of Bash script.

Not every feature of WordPress has been implemented, but it has most of the basics.

Notes:
1. This convention is not sustainable but indicative two letter names are. WordBash architecture is specifically designed to make the use of many small names understandable and therefore manageable.
2. Except for a couple, and they are out of place and I should change them.