Just because you can doesn't mean you should.
-
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.
Yup, I'm pro-parenthesis too. Real important in Regular Expressions as well.
-
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 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. :mad: 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.
-
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. :mad: 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.
-
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. :mad: 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.
-
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.
-
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 agree with you that the code is just a pain.
Quote:
Somebody sure put a lot of faith that the order of evaluation, especially short-circuit evaluation, would remain the same across compilers!
I would. It better. If it's not, it's not C spec and the documentation better have that in big red flashing letters.
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.
-
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.
-
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. :mad: 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.
Any employee who thinks he has "job security" should be summarily fired.
-
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?). -
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.
-
I agree with you that the code is just a pain.
Quote:
Somebody sure put a lot of faith that the order of evaluation, especially short-circuit evaluation, would remain the same across compilers!
I would. It better. If it's not, it's not C spec and the documentation better have that in big red flashing letters.
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.
Oh, ever hear of Caché? (The "database".) Its not-quite-SQL language doesn't honor order-of-operations! (But it's faaaasssst!)
-
Oh, ever hear of Caché? (The "database".) Its not-quite-SQL language doesn't honor order-of-operations! (But it's faaaasssst!)
that seems kind of pointless. How can I tell what it's doing? oh never mind. it's just silly. i don't even want to know. :laugh:
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.
-
Hmmmm, Looks like Sebastiano Vigna[^] wrote that code back in 1998 shortly after leaving Milano. Best Wishes, -David Delaune
-
Any employee who thinks he has "job security" should be summarily fired.
-
Well, I searched for the code snippit and found it in the NE editor source code[^] dated 1998. Best Wishes, -David Delaune
Very good! I like ne and it is an excellent editor! My hat is off to Sebastian. I was using it back in the late 1990's and adapted to run on AIX when I was doing work out of Chicago in Australia and London over a 9600BPS links. I had cause to want to run it recently for a project and resurrected it. I love it's ease of use and functionality, but the code is difficult to follow. I would love to meet Sebastian--he must be one brilliant son of a gun!
-
Any employee who thinks he has "job security" should be summarily fired.
Unless of course the job security is because of competence.
Wrong is evil and must be defeated. - Jeff Ello
-
Well, I searched for the code snippit and found it in the NE editor source code[^] dated 1998. Best Wishes, -David Delaune
