• bvs23bkv33 (unregistered)

    Log.commentsStart("first")

  • Hasseman (unregistered)

    Log.commentEnd(frist")

  • My name (unregistered)

    It stil has the try-cache comment...

  • Huppenzuppen (unregistered) in reply to My name

    and a wrong "it's"

  • iggy (unregistered) in reply to My name

    looks like he was way ahead on Meltdown und Spectre with the processor when processing a try-cache statement ... ;)

  • Quite (unregistered)

    ... so exactly why do you need to override it in the first place? It just calls the base version.

  • Sally Flynn (unregistered)

    Given the updated version literally only calls the base method, why not just delete the override?

  • A-Nony-Mouse... (unregistered)

    Looks like a bunch of "cry {} natch {}" :)

  • Brian (unregistered)

    What's wrong with logging function entry/exit? Provided it's done in a smart way, of course, in which it can be enabled/disabled for the smallest reasonable subset of code that you wish to debug, such logging can prove invaluable for tracing the code flow through a complex system. Especially when investigating timing-related problems where step-by-step debugging may not be feasible... such as in a multithreaded environment.

  • 🤷 (unregistered)

    Elegant desgin. But "Make sure we loop only once" is a wrong comment. It loops 0 times.

  • Donald Klopper (google)

    Don't throw stones if you live in a glass house.

  • DQ (unregistered)

    I love the fact he not only sets bLoop to false but also uses a break. He really wants to be sure the loop only gets executed once!
    I get the idea of easily disabling an entire block of code (not that I would do it like this), but then why not just write

    if (true)
    {
      ..
    }
    
  • Mike (unregistered) in reply to Brian

    I mean, at least do it with aspects or something

  • What? I'm not giving you my name. (unregistered)

    No WTF there. Just another dev paid by LOC.

  • Andreas (google) in reply to Quite

    But it does that without the Log.LogEntry()-call, which (I guess) does nothing.

  • unixcorn (unregistered)

    Clearly the man was someone paid by the keystroke and not someone that was encouraged to write clean, compact code.

  • Andreas (google) in reply to Brian

    I'm pretty sure that Log.methodEntry(String) and Log.methodExit(String) just write a predefined text with the given String to a log somewhere and don't produce objects and Log-Sections based on the given String and calling Method.

  • AnotherAnon (unregistered)

    I know such a person. But instead of catching Exceptions we had an

    On Error Goto [methodname]_Err

    And every Method ended with

    [methodname]_End: Exit Function ' **************************************** Error Handling ******************************************* [methodname]_Err: DisplayError("some explicit message stuff written in the same pattern every f..ing time") End Function

    It was the person I worked for in a small software company. I quitted that job as soon as I had found another one.

  • Anon (unregistered)

    i whiled away my time reading this. Thanks for the post

  • TheRealMan (unregistered)

    I mean, if you're swallowing exceptions, isn't it a try-cache block?

  • Harrow (unregistered)

    I don't see the connection between The Man's horrid coding and the two ways of accumulating experience. Anon does not know what kind of code The Man wrote when he had no experience. Perhaps every single atrocity The man inflicts on his code base is the result of a painful but instructive experience.

  • TheRealWTF(tm) (unregistered) in reply to Quite

    Hush! You're not supposed to mention, or even just notice, me.

  • CSharp (unregistered)

    Farhad, is that you, "The Man", or you're the disciple of "The Man"?

  • siciac (unregistered) in reply to Harrow

    I don't see the connection between The Man's horrid coding and the two ways of accumulating experience.

    The style looks like a very highly refined version of some bad ideas, and especially bad ideas that have persisted because he's never tried them as the new guy.

  • siciac (unregistered) in reply to Brian

    What's wrong with logging function entry/exit? Provided it's done in a smart way, of course, in which it can be enabled/disabled for the smallest reasonable subset of code that you wish to debug, such logging can prove invaluable for tracing the code flow through a complex system.

    Right, and the smart thing is generally the easiest and simplest. And the simplest way to debug any problem is always going to be to debug that problem, and not hypothetical problems. That would mean writing log statements suited to the problem, where you think the problem exists, rather than adding crap you don't use to every method in the entire code base.

    Especially when investigating timing-related problems where step-by-step debugging may not be feasible... such as in a multithreaded environment.

    Or, you know, just use a profiler.

  • ooOOooGa (unregistered)

    My personal favorite on this is the redundancy in the single-pass while loop pattern. It has the boolean guard variable 'flag' that will prevent the loop from executing a second time, and it also has a break statement at the end of the block. For when you have to be doubly sure that the while loop construct never does its job.

  • gnasher729 (unregistered) in reply to ooOOooGa

    There's the hope that a decent compiler will get rid of the whole loop variable nonsense without generating any code.

  • Anonymous (unregistered) in reply to siciac

    If you're logging where you think the problem exists, it means there's a problem.

    A problem you weren't logging.

    A problem that you can't travel back in time to reproduce.

    So you're really not doing any better than the Entry/Exit logging.

    Instead, you should have said, when you were writing whatever it is, "Hey this is a thing that shouldn't happen, so I should wrap it in a try/catch and log the problem close to the source, where I'll have context, because experience has taught all of us that whenever something should never happen in code, it will happen constantly, and be impossible to debug since I think it can't happen!"

  • (nodebb)

    The comments on the new function don't match the content of the function at all. The next developer who will read the code will not know what the comment is about. It should have been his commit message

  • LittleAlex (unregistered) in reply to siciac

    Obviously you never wrote Software other than for yourself. You can't add logging to the software after it has been delivered to your customers. No one is going to pay you for the effort of creating a special debugging version of your software for every case where a customer has a problem. No customer is going to install a debug version of the software just to get a log file for you.

    And you very much do not understand what "timing problems" are. Not "performance problems" - for those you use a profiler. "Timing problems" means: Race conditions and similar problems, where certain bugs will not happen all the time, but only if a certain "timing" happens. For example when one thread is slower than usually and a required barrier is missing, a second thread fails to work correctly, because it wrongly assumes the first thread already did provide a required precondition.

  • Block (unregistered)

    I like the re-implementation of IF using WHILE break;

  • nameofanotheruser (unregistered)

    I wondering if this is even true, why would someone rape code that hard..

  • Zenith (unregistered)

    "The intent was to keep the application from ever crashing. There was no concept of rolling the error up to a place where it could be properly handled."

    Tell me one time that you ever saw anybody actually do this and not simply hide the error behind "oops, something happened, try again."

    It's much smarter, in practice, to check the return value of every function call and throw exceptions up starting at the point of failure. Done properly, you get a stack of "call to function X failed" with the actual error, often times even in English, that started this at the bottom. At the recognized starting points, typically your UI (window or page), this list is parsed for display and not turned into an outright crash with another throw. The issue, as always, is competent developers. They need to operate consistently, check return values, provide useful error messages, and break down problems into small parts so you're not poring over a 40-page function struggling to determine which call to some function actually failed. If you do this, you don't even need a debugger; if business logic has you stepping through breakpoints, you, your team, or your architect(s) have screwed up.

    People like to say no software is good or all software has bugs. That's because they write garbage and make excuses like "all software has bugs."

  • I'm Okay With This (unregistered) in reply to Brian

    Came here to say the same. TRWTF isn't in entry/exit logging, it's in (apparently) having just one log level. Log entry/exit at the least important level, and activate them only when needed and/or on development environments, job done.

  • Adam Tolley (google) in reply to Brian

    Whats wrong with entry and exit logging? Well other than adding a shit-ton of hay on top of the needle, in a multi-threaded environment you would get useless and overlapping logs. Better to gather some context, and log on an error, which would never happen since all errors are swallowed anyway.

  • gigaplex (unregistered) in reply to Zenith

    Relying on call stacks in error message dialogs rarely works sufficiently in practice. Obfuscation usually hides most of the useful details on what functions were called, and users rarely take screenshots of the error message and just complain that it failed. Once they dismiss it, it's gone.

  • foxyshadis (unregistered) in reply to Zenith

    I mean all software does have bugs, but it's the developer's decision whether they're clever little bugs that are only seen once in a blue moon, or abjectly stupid bugs in every method that cause a constant rain of support calls, and reinforce users' perception that computers exist only to frustrate us.

  • (nodebb)

    There are ways to make entry and exit logging work in a multithreaded environment, such as stamping the thread ID (or session ID for web apps) into the log message prefix. But it's always verbose as heck and something you only do if you must and at very fine debugging levels. (If you have AOP available, it's a reasonably good use for it since it lets you keep all that crap out of the source…)

  • Barf4Eva (unregistered)

    ugh.... I almost feel this shouldn't be real...

  • Barf4Eva (unregistered)

    ugh.... I almost feel this shouldn't be real...

  • JTK (unregistered)
    strFields = null; // op: why set local var to null?

    Because way back when, Visual Basic would sometimes leak objects if they weren't set to Nothing before the function returned.

  • Diego (unregistered) in reply to Brian

    AOP. That kind of logging is a cross-cutting concern that could easily be encapsulated as an Advice, thus avoiding the extra code and its boiler-plate

Leave a comment on “Whiling Away the Time”

Log In or post as a guest

Replying to comment #:

« Return to Article