|
We don't need no stinkin' grammar police!
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Explanation[^]
Thank you so much for the condescending tone.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Icons? What are those?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Tripping through some older but still used C code, I found this section:
action a;
if ((a = hash_table[r]) && !cmdcmp(commands[--a].name, p)
|| (a = short_hash_table[r]) && !cmdcmp(commands[--a].short_name, p)) r = a;
else r = -1;
Somebody sure put a lot of faith that the order of evaluation, especially short-circuit evaluation, would remain the same across compilers!
Of course, the programmer saved a couple of characters by excluding four(?) unnecessary parens.
Upon further investigation, I found many instances of this type of statement structure. Apparently that was the preferred coding style. So, I'm guessing the programmer probably saved 100 characters. But it takes a lot of time to examine each statement and hopefully understand what is going on.
|
|
|
|
|
I hate that kind of stuff. I always add the redundant parenthesis because I want to be explicit about what is going on and I find it helps in deciphering the statement. I do NOT want to rely on the precedence order.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Preach it brother!
Software Zen: delete this;
|
|
|
|
|
Yup, I'm pro-parenthesis too. Real important in Regular Expressions as well.
|
|
|
|
|
caveat with parenthesis in regular expressions. Unfortunately, with some engines () creates an unavoidable capture (no way to turn it off unlike in PCRE or .net regex)
So if you're using like, Microsoft Visual Studio search and replace w/ regex (which i have to from time to time) it pays not to use extra parens. You're not maintaining that regex "code" anyway and the parens just make it so you have to keep advancing $1, $2, to $3 for each group and you only get 9 of them so it's maybe not the best idea to use extras.
I bring this up because 50% of the time i'm not tokenizing i'm using regex in something like a search box and the above applies.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Well, sure, but with some rather complex ones which are hard-coded in a program.
The OR operator in particular causes me trouble, so I use parentheses, e.g. ((foo)|(bar))
And often with the Explicit Capture option.
.net's engine is so feature-rich.
I was working with SPLUNK over the summer and was stunned by the lack of flexibility in that engine (PCRE?).
|
|
|
|
|
I've never heard of splunk but i'm actually far more comfortable with the non-backtracking subset of regex - everything that can be boiled down to () | or *
That's because i mostly use them with tokenizing.
But honestly i've found if you need backtracking, regex might not be the best tool anyway, because it quickly becomes cumbersome with complex expressions.
In one of my fancier tokenizers i gave you ways to break up the regex into reusable bits if you liked to keep them manageable. I may or may not do that again but i never really used it. Some people hate regex tho.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Then you should use LISP!
ROTFLMAO...
I agree about NOT counting on short circuiting, and using parenthesis.
In our coding standards we consider them the "White Space" if evaluations.
|
|
|
|
|
I once had a colleague who believed in obfuscating his C code to the maximum. He did not add comments to his code or any documentation of any kind. I believe he thought if he was the only one to understand his code, it provided a kind of job security. 
All went well for him until I was promoted into a position where he reported to me. One of my first actions was to fire him.
|
|
|
|
|
|
In the name of the code-base, the style guidelines, and the future maintainers, we say - comment  (And just name things well.)
|
|
|
|
|
Any employee who thinks he has "job security" should be summarily fired.
|
|
|
|
|
Graveyards are filled with people who were indispensable.
|
|
|
|
|
Unless of course the job security is because of competence.
|
|
|
|
|
Competence is not a significant factor in job security according to my experience. We've had layoffs every 6-9 months for the last several years. In that time my team has gone from 17 down to 5, although now it's back up to 6. The most common factor in the layoffs was which product you were on, followed by productivity, followed by age/salary.
Note that competence and productivity are not equivalent.
Software Zen: delete this;
|
|
|
|
|
I'm retired now, but when I was the senior developer coding for job security was grounds for termination. Over the course of my career, I spent far, far too much time decipheriing and rewriting such code to be understandable.
It's a hard life, but somebody's got to live it if only to act as an inspiration to others.
- Dan Best
|
|
|
|
|
|
Hmmmm,
Looks like Sebastiano Vigna[^] wrote that code back in 1998 shortly after leaving Milano.
Best Wishes,
-David Delaune
|
|
|
|
|
|
|
Good one! I deserved that.
How did you come up with S. Vigna?
|
|
|
|
|
Well,
I searched for the code snippit and found it in the NE editor source code[^] dated 1998.
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
