darwinist said:
Richard Cornford wrote:
Sure if they achieve it equally well.
But they can achieve it equally well .You introduced and imposed your
interpretation of the dollar symbol, there is no other possible source
of meaning for the symbol in your context (beyond something referring to
specific types of currency, or machine generated Identifiers). If you
can arbitrarily attach your own meaning to any one symbol you could
attach that meaning to any other ('symbol' here being more than just a
single character, as there are not that many of them available, but
anything (implying character sequence) that could be symbolic of the
function grouping used).
Inevitably, so advantages follow from the code satisfying the
(preferably more established) expectations of the reader.
What development system is this where someone can't look up a
function immediately?
Finding a function definition in a source code files does not say
anything about how that file is created, and an indicator of a machine
generated Identifier implies a fully or partly machine generated file
and so the need to appreciate the how, where and why of its creation.
What they expect is one factor.
Quite an important factor.
Overall clarity and readability is what matters
It is what matters. Does disappointing a reasonable expectation, while
not providing any relevant implicit meaning (the implicit meaning of $
being currency related) in the Identifier, really contribute to clarity
or readability?
and I suggest a single symbol (perhaps you could name
a more appropriate one)
I would prefer a character sequnce (More sometimes is more).
make this distinction clear and takes about 10
seconds to familiarise yourself with.
I have already disputed your "10 seconds". I still think that you are
seeing this only from the perspective of someone intimately familiar
with the naming convention you have chosen to use. It is inevitable that
you would find it easy to see things from that perspective, but you
should also be able to see that there are advantages in being able to se
things from other perspectives (particularly if working in GUI design).
If you assumed no knowledge of any specific meaning to the $ symbol
where you use it and re-examined the situation it should be fairly
obvious that your source code gains no clarity through its use, and if
you assumed an (any) alternative meaning that the code actually becomes
misleading.
Lets consider the inherent meaning of $, as indicative of a particular
type of currency and examine your functions- $( ... ), $del(id) and
$make( ... ). Intuition might suggest something related to accounting
and/or currency formatting. The reaming parts of the Identifiers, the
'del' and 'make', certainly do not preclude a fiscally related
interpretation.
The javascript spec doesn't describe the actual
programming platforms we use, not completelely.
The deviations between ECMA 262 and ECMAScript implementations (such as
JavaScript(tm) and JScript) are minimal and largely of no practical
significance. And over time the number of implementation bugs has
diminished, with changes being towards conformance with the
specification.
We need to write for the interpreters that people use,
not the specs of an interpreter that should exist.
You are proposing a practical impossibility. You have no way of
determining what interpreters people actually use, and are not in a
position to gather enough information about all of them anyway.
It is much more practical to write javascript to ECMA 262 and avoid the
few areas where problems are known to exist than to attempt to
accumulate a specific knowledge of the behaviour of all implementations
into a useable sub-set (and even if the latter was realistic the
outcome would likely be the same anyway).
Underscores could work. I tend to associate them with system
calls, myself.
The most common use of leading underscores is to indicate object
properties that are 'private' by naming convention, and so that would be
expectation best anticipated in others.
Well ok, but I really think its inclusion in the spec is
giving it undue importance in your mind.
The effect of its inclusion in the spec is to make it likely to be
familiar to people who know javascript well. The likelihood of
familiarity is what results in the expectation of an expectation, and it
is not acting to disappoint that expectation that I consider
important/significant in the choice of conventions to apply to code
authoring style.
Not if it's more obscure, but in a properly defined context:
"del(element);"
is fairly clear to any programmer where
"removeDomElementById(element);"
is redundant and less readable.
Without the caveat "a properly defined context" that statement would be
very questionable. For a start - element - would be a poor choice of
Identifier for a value that was a string representing an ID, and -
del(elementId); - is not unambiguously acting upon the element referred
to by the ID string.
The longer the function and method calls the more often you
have to either split functions across lines,
Properly indented, I don't have a problem with splitting a function call
across lines. My comment was intended to suggest that a function call
would not often be mixed with other code on the same line (or in the
same expression) and so that there was little need for function names to
be too visually distinct in the source code.
or calculate parameters separately before passing them.
All this means less gets said per screen.
I adopted the basic dollar function idea for getting
elements and extended it.
That sounds personal rather than 'common practice'.
You couldn't dismiss that possibility no matter what the
variable was called,
Without the leading $ symbol there would be no reason for introducing
the possibility that the Identifier was machine generated.
since you say most javascript is written by one group of
poorly informed individuals and cut-and-pasted by another.
It would also be an action against the inherent understandability of
javascript source code to include a machine generated Identifier that
did not commence with a $ symbol.
Geez: search-> "function $del("-> "all files in project"->"find";
Now show me the search term for the back-end that, when it is not found,
verifies that the Identifier/function definition is _not_ machine
generated? Say the back-end is (100%) Java, what do you search for? What
if it is N tier written in a number of languages?
It behaves like punctuation, and punctuation tells you
about structure. Interacting with the gui deserves a kind
of punctuation, or at least can benefit from one.
That is only going to work if _every_ interaction with the DOM is
similarly wrapped in a function call, even something as simple as
reading a value from a form element once. Apart from the performance hit
of doing that, you would start to get to the point where the whole set
of functions beginning with $ symbols was so large that they needed
distinguishing names anyway.
Functions should not try to fit the language they are written
in,
Which has no relationship to giving functions names that say something
about what they do.
but rather the application they are creating. That is
their "natural" meaning.
That sounds impressive, but doesn't appear to mean anything (that is, it
sounds like marketing-speak).
Function names should say enough to state what the function is doing at
the point where the function is called, and without reference to the
actual function definition.
I gave a counter-argument, you just repeated yourself.
I did not see a counter argument, only an assertion of a relationship
along the lines of; "If you can express the initial prototype more
quickly" then ' there _is_ a relationship between an ability to optimise
for speed and the use of any particular naming convention'. Where the
latter does not follow from the former unless there was demonstration
that a "particular naming convention" (rather than naming conventions in
general) directly resulted in an ability to "express the initial
prototype more quickly" (whatever that is intended to mean).
You have not demonstrated that any "particular naming convention" (or
that your particular naming convention) has any benefits (presumably
resulting in the quicker expression of prototypes) that cannot be found
in other naming conventions.
That can only be taken so far, before you are repeating
yourself unnecessarily to anyone who has spent more than
ten minutes with your code.
A call to the same function is a call to the same function whatever the
name of that function is.
Of course function names should have inherent meaning. What
kind, how much,
Sufficient that it becomes unnecessary to cross-reference the function
call with the function definition, certainly whenever the function
definition is expected to be some distance form the call.
and in what context should that meaning be "inherent"?
If a context is beyond 'an understanding of the native language of the
programmer' (or at least the language that (s)he used when writing the
Identifiers, as that sometimes is not their native language) then the
meaning is not 'inherent'.
That is the point of contention.
Conventions provide meaning beyond what is inherent. For a programmer
common, well known/recognised conventions may provide meaning that is
approaching 'inherent' in its significance; and expectation that
something will mean something specific.
No but single words with punctuation between are clearer than
javascript method calls.
The choice between camel-case and using underscores to separate words in
Identifiers either arbitrary or the subject of convention (possibly
formalised). I am told that when reading most of the time it is the
recognition of patterns in the symbols on a page that allows
understanding, rather than the parsing of sequences of letters. In that
way a camel-case Identifier can be seen as the same on each occasion it
is referenced and its meaning only derived from the sequence of
characters it contains on the first reference.
If camel-case really were an issue we would already be habitually using
underscores to separate words in Identifiers.
Many javascript applications are installed across the world
over networks and updated often. Downloadability is part of
a web-pages usability.
But given that HTTP 1.1 requires user agents and servers to support zip
compression/decompression downloadability is (or could/should be)
related to the post-compression nature of the source, and repetition is
what compresses best. The practical impact of may occurrences of the
same 10-20 characters of source text is likely to be negligible.
The main purpose of my desktop was to show how easily and
concisely this functionality can be achieved. Any customised
content or style would need to be on top of this and so it's
even more important to keep down the size of the code.
Or; the implied necessity to integrate the existing code with the
javascript code needed for any real application makes it particularly
important to maximise the readability of the code, especially for the
experienced javascript programmers who are the only people who should
sensibly be employed in writing a web application sufficiently complex
as to require an in-browser windowing GUI.
Richard.