Adobe's Coding Conventions Leave Me Asking "Why??"
I just took a quick first pass through Adobe's newly-published Flex Coding Conventions, and while I agree with much of what is in there, a few items leave me scratching my head. I think it would have been useful for them to offer some sort of rationale behind the recommendations, not just "do this, not that" mandates. By way of a few examples:
Use Array literals rather than new Array().
Isn't "new Array()" more consistent with the way every other kind of object is instantiated? "[]" is a shorthand syntax - I have found shorthand generally to be something to be avoided, because it requires a deeper familiarity with a language than a generalist programmer would possess. I raise the same objection to the recommendations for using Object literals, RegExp literals, and so forth. Consistency is key.
Don't use unnecessary parentheses with common operators such as +, -, *, /, &&, ||, <, <=, >, >=, ==, and !=.
I favor explicit groups, not implicit ones. In my opinion, this: var e:Number = (a * b) / (c + d); is better than this: var e:Number = a * b / (c + d); because it removes ambiguity over whether b is divided by (c + d) or a * b is divided by (c + d).
If the various branches of an if/else statement involve single statements, don't make them into blocks.
This just makes your code less readable, and introduces an inconsistency in the way the syntax is written. Why have a special case for branches that contain a single statement? This feels more like the personal preference of an experienced developer than a bona fide "best practice" for teams. Indeed, the recommendation for "while" statements is exactly the opposite.
Use int for integers, even if they can't be negative. Use uint only for RGB colors, bit masks, and other non-numeric values.
Why???? What's the point in having a uint if you're only going to use it for things other than unsigned integers?
These are just a few that jumped out at me, because they seemed arbitrary exceptions to the norm. "Best practices" should promote a coding standard that favors minimal variation in syntax over quick coding time, easy understanding over minor performance gains, etc. Overall, I think they're on the right track - but if they're going to create all kinds of exceptions to their own rules, they should provide more explanation.
One more - this is just whack:
var a:Array /* of String */ = [];
The language does not support typed arrays. If you need a typed array, extend ArrayCollection and add your own type-checking. Cluttering up your code with comments like this doesn't offer any compile-time type-checking, and is much less readable than var a:MovieClipArray = new MovieClipArray();
Use Array literals rather than new Array().
Isn't "new Array()" more consistent with the way every other kind of object is instantiated? "[]" is a shorthand syntax - I have found shorthand generally to be something to be avoided, because it requires a deeper familiarity with a language than a generalist programmer would possess. I raise the same objection to the recommendations for using Object literals, RegExp literals, and so forth. Consistency is key.
Don't use unnecessary parentheses with common operators such as +, -, *, /, &&, ||, <, <=, >, >=, ==, and !=.
I favor explicit groups, not implicit ones. In my opinion, this: var e:Number = (a * b) / (c + d); is better than this: var e:Number = a * b / (c + d); because it removes ambiguity over whether b is divided by (c + d) or a * b is divided by (c + d).
If the various branches of an if/else statement involve single statements, don't make them into blocks.
This just makes your code less readable, and introduces an inconsistency in the way the syntax is written. Why have a special case for branches that contain a single statement? This feels more like the personal preference of an experienced developer than a bona fide "best practice" for teams. Indeed, the recommendation for "while" statements is exactly the opposite.
Use int for integers, even if they can't be negative. Use uint only for RGB colors, bit masks, and other non-numeric values.
Why???? What's the point in having a uint if you're only going to use it for things other than unsigned integers?
These are just a few that jumped out at me, because they seemed arbitrary exceptions to the norm. "Best practices" should promote a coding standard that favors minimal variation in syntax over quick coding time, easy understanding over minor performance gains, etc. Overall, I think they're on the right track - but if they're going to create all kinds of exceptions to their own rules, they should provide more explanation.
One more - this is just whack:
var a:Array /* of String */ = [];
The language does not support typed arrays. If you need a typed array, extend ArrayCollection and add your own type-checking. Cluttering up your code with comments like this doesn't offer any compile-time type-checking, and is much less readable than var a:MovieClipArray = new MovieClipArray();
10 Comments:
About typed arrays... Adobe did include a metadata tag for compile-time typing of arrays: ArrayElementType, so I don't know why they wouldn't use that.
about int vs uint, i have always heard that int is an order of magnitude faster in the current flash player, so its always preferable to use int over uint except where necessary.
Another comment regarding the uint/int debate -
I've noticed that a lot of coders use uint religiously. However, I've read a few articles that suggest that uint can be 200-400% SLOWER than the int datatype. So, I pretty much never use uint.
PS - here's a post by G Skinner regarding the issue:
http://tinyurl.com/49z8l4
>> it removes ambiguity over whether b is divided by (c + d) or a * b is divided by (c + d). <<
Mathematically there is no difference between the two.
The AVM may think so, but at 2 AM my brain is not so sure - and that's really the point of best practices. It's easy to forget the execution order:
trace(6+6/3*3) // 12
trace(6+6/(3*3)) // 6.666666666666667
trace((6+6)/(3*3)) // 1.3333333333333333
trace(6+(6/(3*3))) // 6.666666666666667
It's simply easier to predict the outcome when you explicitly define the sub-calculations.
The major issue I have with uint in ANY language is that they create very hard to find bugs when they wrap because of casting signed ints or what have you. A rather stupidly simple and visible example:
var i:int = -1;
...
for( var k:unint = i; k < i; k++ )
doThisForaLooongTime();
Bah, thats of course:
for( var k:uint = 0; k < i; k++ )
ehhh, sorry? but where´s here your problem? Is it about the teamwork? In my eyes there is nothing to complaint about, it´s just about learning it. Not the first time in your life, maybe?
當舖
專利
專利
關鍵字
專利
當舖
存證信函
存證信函
關鍵字
存證信函
當舖
商標
商標設計
自創品牌
商標
關鍵字
商標
當舖
花蓮|花蓮民宿|花蓮|花蓮民宿|花蓮旅遊|花蓮民宿|花蓮美食|花蓮旅遊|花蓮黃頁網路電話簿|花蓮入口網|花蓮民宿黃頁
花蓮旅遊|花蓮美食|花蓮飯店|花蓮住宿|花蓮民宿|花蓮民宿|花蓮|花蓮|
花蓮|花蓮民宿|花蓮旅遊|花蓮美食|花蓮住宿|花蓮飯店|花蓮旅館|花蓮|花蓮民宿|花蓮民宿推薦|花蓮民宿市區|花蓮民宿王|花蓮民宿網|花蓮民宿資訊網|花蓮民宿悠遊網|花蓮民宿交流網|花蓮海景民宿|花蓮海邊民宿|花蓮海岸民宿|花蓮旅遊民宿|花蓮|花蓮旅遊|花蓮廣告|花蓮民宿|花蓮房屋|花蓮汽車旅館|花蓮派報|花蓮飯店|花蓮派報|花蓮旅館|花蓮美食|花蓮餐廳|花蓮小吃|花蓮名產|花蓮工作|花蓮新聞|花蓮租車|花蓮入口網|花蓮旅遊|花蓮旅遊|花蓮旅遊景點|花蓮旅遊|花蓮旅遊景點|花蓮民宿|花蓮旅遊|花蓮房仲|花蓮旅遊景點|花蓮美食|花蓮餐廳|花蓮小吃|花蓮名產|花蓮縣長|花蓮租車旅遊網|花蓮行易旅遊資訊網|
Post a Comment
<< Home