• (cs) in reply to S
    S:
    chubertdev:
    I believe that that is called "technical debt."

    I've made it a personal rule that when I "inherit" a codebase, that's the cleanup. Don't break anything, but don't hide new warnings because there are so many old ones.

    You're right - except that doing so simply isn't an option. Partly because of the time it would require - months for a codebase of this size - and partly because of the risk of exposing customers to unnecessary large-scale code changes. Remember what I said about the code going back to Java 1.0, and guess what the test coverage looks like for most of it. Newer parts have automated tests, certainly - but those are the bits least in need of cleanup...

    Fortunately for me, I can choose a job where this isn't an issue. I hate being a code janitor, cleaning up everyone's vomit with sawdust.

  • foo (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    I think that the reverse style is ugly, but it does do what it has to. C should not have redefined the = operator, but it is the world we live.
    While I agree on an abstract level, I still wonder what's a better practical alternative.

    I've programmed in Pascal for a while, and typing := for assignment (which is by far the most common operator in most programs) is a bit annoying. The Basic way of using a single operator also has drawbacks, as have been discussed here various times.

    So C chose the pragmatic approach of using the simplest token = for the most common operator, even if it resulted in the ugly == for equality. Today, in Unicode, you could probably easily find different suitable characters for both, but if you're limited to ASCII (or characters you can easily type), I still wonder what would be the optimal choice ...

  • (cs)
    int c ۩ getValue("test");
    if(c = 5) {
       ...
    }
    
  • ACM (unregistered) in reply to foo
    foo:
    Very subtle, unless you use a modern compiler with warnings, or bother to fucking read the previous comments before making a point already refuted yesterday.
    Or an alternative which is very useful: have your IDE warn about it. In IDEA its called "nested assignments" and you can select that to be a warning. And it will highlight your code right after making that error.

    Besides, in Java it would only work with booleans and who in his right mind would test booleans using constants?

    I wouldn't do this:

    if(value == true){}
    // or
    if(value == false){}
    

    I would test them like so:

    if(value){}
    // and
    if(!value){}
    

    So the main case advocated here in Java is in itself an example of redundant (and thus bad) code ;)

    Even without a highlight on nested assignments, my IDE would still highlight both as being always true or always false (and the variant with == as having being able to simplify).

    With two variables, you'd be never get a compiler error either way. So the only scenario you could save some errors by forcing a compile error would be where one of the sides is a functioncall and the other is a variable.

    if(someCall() = a){} // This would be a error
    // Whereas this might be silent
    if(a = someCall()){} // This would be a error
    

    But I actually very seldomly compare two booleans with eachother... I rarely want to test whether the booleans are either both false or both true and have that trigger the same blockstatement. The case where I want to assign a variable and directly test its outcome is slightly more common in the Java-codebases I work with.

  • (cs) in reply to Pock Suppet
    Pock Suppet:
    Can we kill this constant == variable pattern yet? You're not testing the value of null or 3 or PI; you're testing the variable. Object-verb-subject order doesn't grammatically match very many programming languages (or many spoken languages, for that matter), so stop using it! Nao!

    No.

  • (cs) in reply to EuroGuy
    EuroGuy:
    I also dare claim that 90% of the people who use the reverse notation don't do it because they sincerely believe it prevents bugs, but more so because it is another way to show that they are 1337 programmers.

    Also, those that understand the programming language well would never confuse = and ==. It never happened to me; at least it has never been proven! So that returns me to the point I made earlier: the reverse notation might be useful for amateur programmers, but they wouldn't be aware about this trick. The seasoned programmers who know it, most likely don't need it.

    You are incorrect. You are assuming smugness simply because you disagree with the reasoning. That's idiotic.

    You misunderstand the issue. It doesn't matter how well you know the language. People make typos. If you always do it in the "unnatural" order, then the compiler finds your typos, whereas if you do it the "natural" way, you have a bug you may or may not find.

  • real-modo (unregistered) in reply to Gunslnger
    Gunslnger:
    You misunderstand the issue. It doesn't matter how well you know the language. People make typos. If you always do it in the "unnatural" order, then the compiler finds your typos, whereas if you do it the "natural" way, you have a bug you may or may not find.
    Why wouldn't such a bug be caught by a unit test?

    People have been bandying around the phrase "professional programmer" here.

    Professional programmers have the computer catch their bugs.

    Professional programmers also know that code is read hundreds of times more often than it is written, so they write their code for other programmers to read. (Only novices worry about writing code to make the computer do what they want. Of course a professional can do that.)

    As a matter of professional courtesy to their peers, professional programmers write their code so that (1) it can be read quickly, and (2) hasty readers will form a correct impression of what the code does.

    Using a "natural" syntax is part of (1).

    If you're worried about uncaught errors of this sort, you're still at novice level. When code readability is your primary concern, you can call yourself professional.

  • gcc -Wall (unregistered) in reply to chubertdev
    chubertdev:
    int c ۩ getValue("test");
    if(c = 5) {
       ...
    }
    
    foo.c: In function 'main':
    foo.c:6:1: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
    
  • Matt (unregistered) in reply to EuroGuy

    Proper Yoda style would be "null aReceiver =" (Null, aReceiver is).

  • gnasher729 (unregistered) in reply to Nick
    Nick:
    I've programmed in C/C++ for so long that "ptr != NULL" or "ptr == NULL" always makes me look twice, because I'm so used to just "if(ptr)", read as "if ptr", or "if(!ptr)", read as "if no(t) ptr". I've never confused those two but the comparison versions remind me of "if(b == true)" and "if(b != false)" with booleans which is basically the equivalent of ==NULL and != NULL respectively --- huh?
    bools are bools and pointers are pointers. and, or, not are boolean operators and should be used with bools, not with pointers. Pointers shouldn't be treated as booleans.
  • Meep (unregistered) in reply to Lothar
    Lothar:
    String.replaceAll expects a regular expression, so the given helper method is not a real reinvention of the wheel.

    But String.replace does not take a regex.

  • gcc -Wall (unregistered) in reply to gnasher729
    gnasher729:
    Nick:
    I've programmed in C/C++ for so long that "ptr != NULL" or "ptr == NULL" always makes me look twice, because I'm so used to just "if(ptr)", read as "if ptr", or "if(!ptr)", read as "if no(t) ptr". I've never confused those two but the comparison versions remind me of "if(b == true)" and "if(b != false)" with booleans which is basically the equivalent of ==NULL and != NULL respectively --- huh?
    bools are bools and pointers are pointers. and, or, not are boolean operators and should be used with bools, not with pointers. Pointers shouldn't be treated as booleans.
    [citation required]

    I'd go further and say that any object that has meaningful "content exists/doesn't exist" states and where no confusion is possible should be treatable as bool. Fortunately, in C++ I can do that. And you can be happy with your language of choice that doesn't allow it. So we're all happy. ;)

  • randomreader (unregistered)

    That's nothing, Lyle made a templating library to generate templates.

  • hhmg560 (unregistered) in reply to foo
    foo[url="http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html:
    This[/url] is about C, but can be directly applied to our C++ case.
    Their example with the global function pointer takes it too far IMO. Global variables are visible everywhere, so the compiler can't assume where it was last accessed...
  • foo (unregistered) in reply to hhmg560
    hhmg560:
    foo[url="http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html:
    This[/url] is about C, but can be directly applied to our C++ case.
    Their example with the global function pointer takes it too far IMO. Global variables are visible everywhere, so the compiler can't assume where it was last accessed...
    It's declared static, so it's only visible in this compilation unit, so a compiler that can see the whole TU at once (which clang apprently does) can perform this optimization. Of course, it doesn't know when it was last set at runtime, but if it's only ever set to null (UB when called) and one single other value (impl), it can assume it must be the latter in a correct program.

    Now, I do wonder where this particular optimization is useful. But please don't take it to mean I claim it's not useful -- I suppose they did have a reason to implement it, they probably don't like wasting their time.

  • Aufgehaben (unregistered) in reply to eViLegion

    We used to do that at my old job, using indefinite articles for parameters (aValue), definite values for global variables (theValue) and possesive for for member variables (myValue). It worked rather well, it was easy to see where each value came from.

  • (cs) in reply to gcc -Wall
    gcc -Wall:
    chubertdev:
    int c ۩ getValue("test");
    if(c = 5) {
       ...
    }
    
    foo.c: In function 'main':
    foo.c:6:1: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
    

    You'd think it wasn't C code, almost as if it was a fictional language...

  • blah (unregistered) in reply to Tasty

    Japanese is not an Altaic language.

  • abjdhoaz (unregistered) in reply to Dogsworth

    صورمشبات .مشبات . ديكورات مشبات .صورمشبات http://shomane.blogspot.com/

    صورمشبات http://12abjdhoaz.blogspot.com/

  • Neil (unregistered) in reply to foo
    foo:
    return null; unless (null != aReceiver);
    Perl does this sort of thing of course:
    return unless aReceiver;
  • (cs) in reply to Gunslnger
    Gunslnger:
    You misunderstand the issue. It doesn't matter how well you know the language. People make typos. If you always do it in the "unnatural" order, then the compiler finds your typos,
    ...but only in the case where you're comparing a constant to a variable. You'll still have the exact same problem when you're comparing two variables, except now you think you're protected from such errors, and will therefore have an even harder time tracking it down.

    Even if you happen to like the "const == variable" syntax and find it perfectly easy to read and parse, it doesn't actually solve the alleged problem, so that's not a good reason to give for using it. Just say you like it. If you're actually trying to solve this problem then:

    a) use a language that doesn't permit this; or b) configure your compiler to issue a warning or error if you accidentally do this; or c) configure your source control system to refuse check-ins that use this syntax you've decided to disallow; or d) periodically run a source checker to look for this and any other construct you've encountered that causes you problems.

    Any of the above methods will be more effective at actually resolving this issue, and will do so consistently.

  • Luke (unregistered) in reply to zennnnnn

    There are an infinite number of empty strings and all strings so the first example should not halt. If it did however it would return "BobBobBobBobBobBob"....

  • -is (unregistered) in reply to DaveK
    DaveK:
    C-Derb:
    Pock Suppet:
    Can we kill this constant == variable pattern, yet?
    Personally, I think that practice is silly and weird to read, and I would be fine with never seeing it again. Remembering to put your constant on the left side of the comparison operator takes as much effort as remembering to use the comparison operator instead of the assignment operator. So why not make the code more readable?
    People who get thrown by the order of arguments to a commutative operator are TRWTF.

    What he wrote.

Leave a comment on “Stringing a Replacement”

Log In or post as a guest

Replying to comment #:

« Return to Article