On 10/03/2012 12:22, Justin Mclean wrote:
Couldn't you just use var invalidFormat: Number = 0 or 1 ?
I could but then I would be casting a Number to boolean on the other fields.
Well the conversion game from boolean to number is best *read* like this:
var wrongNess: Number = 0.0; // I wouldn't use "count" as it
doesn't mean anything, wrongFactor might be something...
if( invalidFormat ) {
wrongNess = 1.0;
}
if( invalidChar ) {
wrongNess += 1.0
}
if( wrongLength ) {
wrongNess += 1.5:
}
Personally I see bad sides in the one with the missing else ... however: again:
What did the Flex Gui
The SDK code is inconsistent in this case and uses both forms.
Then we should write a consistent shape on a wiki page. (see other
mailinglist entry about code convention in wiki)
I made the experience that programming for possibilities is a very bad idea. I
am not necessarily talking about the performance (which it also affects) but
also the readability.
I think the readability is fine and it has been improved in the latest checked
in version.
I am not of the believe that putting code in function increases
readability. Stepping through with the debugger However: private static
functions are the least evil.
That being said: programming for possibilities is usually a really bad
idea. I think it can be implemented again when its time has come. By
then the structure of the code may already
be entirely different.
Personally it more how people want to use it, standards are only as
good as how much they are used eg country code should in some cases be
used in postcodes but is generally ignored. I've added support and
test cases for it.
Its not about a "standard" its about a definition: What does the
documentation of the tool say? Does it say: "It can verify any code" "It
can verify some code" "It can very special code" "It verifes ITU
standardized", .... etc. I wasn't sure about this, that's all.
May need to support that down the track if any country postcodes
contain alpha characters and use wide characters. Currently I'm not
aware of any.
Actually double width characters can be typed in accidentally easily. If
you hit a wrong key on the keyboard then you suddenly type in
full-width. I think most japanese people are used
to check for single width but it depends on the font and the eye-sight
to spot the differences. The real problem is that that they do use them
in office documents (where they usually write addresses -> copy paste).
However: This "validator" usually sits in front of a server-side
validation - right? Some server-side validation accepts full width, some
doesn't. It should optional. How about using
the character "Ｎ" instead of "N" to check for double width numbers
(only!) and "Ａ" instead of "A" to check for double-width characters.
All this stuff sounds already a lot like reg-exp.
I do not see a need for this to be consistent, does it? Anyways: I will not a
refactoring of this signature for Flex X somewhere.
I think it does need to be consistent with the current validators. Forms will
often use a variety of validators and often place them into a single array so
the entire form can be validated in one go. Having them all work and look the
same makes them easier to use.
Typo on my part: I will *note* a refactoring of the current signatures :)
Then my question would be: Why is it private?
It's not private it's public the "@private" comment is for the documentation so
it handles setters and getters correctly.
I have never had that problem without the "@private" statement but I
admit that I started from a late version of flex to use asdoc.
yours
Martin.
<http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions>
