As the thread author points out in his reply to my post, programming across multiple languages teaches you safe techniques for approaching problems. Sometimes this means typecasting values where there could possibly be any confusion over its meaning.
You can argue that usage of parenthesis is a waste of time.. if one understands the order of the evaluation of the operators then typing ( or ) is wasteful. Further, I'm sure you would argue that understanding the exact order of evaluation of operators is fundamental to programming in Perl. But then this would also demonstrate a lack of experience programming in multiple languages, as not all languages treat precedence the same way.
Therefore one can afford a new programmer to a language the mistake of typecasting something unnecessarily. One can never afford to excuse the programmer who dangerously, however, coding assuming things would just turn out as they expect without much experience behind them. | [reply]
[d/l]
[select] |
Maybe I'm being misunderstood.
I would never fault a beginning Perl programmer for "speaking Perl with a C accent" (see other threads for my description of that).
However, I will always demonstrate "speaking Native Perl" (or "Perl as she is spoke").
In this case, the "int" is definitely redundant, and would get noticed in a code review by my team. Just like the random appearance of "scalar" in definitely scalar contexts, and a dozen other "I don't quite grok Perl" mistakes that I see made on a regular basis.
There is a "native" Perl. I'm teaching it. The llama and the alpaca and the camel define it. My columns and monk postings and usenet comments demonstrate it.
| [reply] |
I certainly am glad I'm not on your programming team. I am always open to seeing better ways of doing things, but I am very picky about working with open minded individuals that like to be the best in their game..
My response to your standard disclaimer is "don't expect me to respect you if you can't show respect yourself."
Also: "don't expect me to think you're good at something if you boast about it a lot." I've met many cowboys in the industry, and they've all got something to prove.
update: I also believe code reviews, when operating at their best, are about finding and commenting on process flaws or techniques that could seriously affect the program's integrity. Maybe code formatting would be important, too, to a team. But nitpicking about using too many parenthesis to be safe, or the use of int() in a redundant fashion, is less about writing good code and more about showing off.. and when someone older starts boasting that is the right way to do it, it is time to quit that company and look for something better.
| [reply]
[d/l] |