Overview
Uniformity
In order to provide the global surfer a uniform experience when using any number of search engines, we require that
you follow a few simple conventions for the naming of your pages.
But, it is also our intention that these conventions do not restrict your creativity, but simply put reasonable envelopes around it. Therefore we have divided the naming conventions into three(3) groups: Required, Preferred, Optional. But, to reiterate, these conventions are for your file naming within the
Further, they are may not be all inclusive nor are they without some overlap and some confusion as we are attempting to map complex reality into a one-dimensional already established file-naming space. Judgment is required. If a file is named inconsistently or not in accordance with our procedures it can always be changed. The naming refers to the individual page file name, not to what you may have titled the page for the user to see on the user's screen.
?You yourself are of course a Level 4 Active Member, so any reference to "member" does not refer to you but
to other members who might be using what you are providing through AEDOK.
Naming Conventions (group 1 of 3) Required
The beginning and the end.
The beginning:
In order to provide inner linkages within the
Suppose your subdomain is intellectualThoughts in our sub domain edu of AEDOK of org.
GUIDELINES
Most words are completely lowercase with the following exceptions:
¿Specific names when used as categories or groups or sections, etc., should be all upper case such as:
HTML
but when used to simply represent the common extension it should be lowercase:
filename.html
Names may be upper/lowercase when multiple words are combined to form a single words that the computer can
process, as is common:
getNameAndCheck
But the first letter should be lowercase only when necessary to do this contraction. Again:
getNameAndCheck
Continuing subdivisions of some function should be separated by single(1) underscore(_):
getName
getName_check
getName_done
If a particular name for a function is best described by multiple words not using the above mentioned
first-letter-capitalized-contraction, such as for example in this sentence, the words should be separated by dash(-):
getName_done_thank-user
Notice that in the above example, "user" is not a subdivision of "thank", but rather, "thank-user" (as a single concept)
is a subdivision of "done".
Notice that whereas this convention is backwards of some, where people use the underscore for connecting words
and the dashes to separate, In reality, visually the dash(-) gives the appearance of connection and the underscores
geve the appearance of separation. Of course, if one changed the font so that the dashes were larger and the
underscores were shorter, the visualization might be reversed. But, this is the convention we have established based
on what we see.
When the above conventions are applied to the general syntax you get the following example:
com_info__HTML_getName_done_thank-user.php
YOU might never need to create the specific name in the previous example because many user functions shall
eventually be defined by AEDOK (or defined by various members and incorporated into the AEDOK library for your
use), such as:
all_all__user_getName_done_thank-user.php
or possibly, because users and members overlap:
all_all__mem_form_getName_done_thank-user.php
which means:
domain all
section all
function member
subFunc fill out the member app form
subSubFunc getName
subSubSubFunc done
subSubSubSubFunc thank user
(The above is not a real example)
The syntax is as follows:
domain underscore(_) section underscore(_) underscore(_) func underscore(_) subFunc underscore(_) subSubFunc
underscore(_) ... dot(.) page-type
Notice the double underscore(_) gives an even greater appearance of separation.
The Individual terms are defined as:
Domain
c com
o org
n net
all all domains
Section
info information
user user
mem member
adm administrative
sub subscription
serv service (not a subscription)
prod product (like a report but
Note that member and user have someone overlapping functionality, but again for the most part those names will be
decided by AEDOK, So there may be some exceptions.
Examples:
Domain Examples:
All web pages in the net domain Begin with n_ except for some of AEDOK information pages, which would start with
all_
Section Examples:
Section
info information
n_info_(yourTopic)
In the above exsmple, the documentation you are providing, say for example a manual, is (your topic). Say for
example, (your topic) is HTML:
n_info__html_...
Nearly all, if not all, of your pages will begin in that manner.
Section Examples:
Section
user user
mem member
adm administrative
sub subscription
serv service (not a subscription)
prod product (like a report but
CONTENT
ALL Words that are contextual to the language or computers technology in general MUST Be hyperlinked to a K
multilevel definition page.
Undesirable Modes & Techniques
Overview
This discussion concerns modes and techniques which are the very modes and techniques currently prolific but we are attempting to overcome. Each topic is introduced by a representative example of the wrong way to do something.
Technique: COMMON/SELDOM USED
"This statement is seldom used."
And then they go on to discuss the statement itself without further consideration of the common/seldom aspect.
Flaw:
The critical flaw here is that they speak as though they are some expert dolling out tidbits of wisdom, not as a teacher elucidating the topic. When a teacher introduces an important concept, he does not just "leave it hanging" as though he didn't even say it. They, on the other hand, do not explain or give any indication (a "hint", if they gave it, only compounding the flaw) as to why this statement is seldom used.
Technique: INTERMIXING VERBS OF SIMILAR MEANING or ADJECTIVES OF SIMILAR
(see javascript scope and life)
/p>
Flaw:
The critical flaw here is