• Greg (unregistered)

    I've worked at a company where one of the coding guidelines was to avoid having multiple exit points in functions if possible, so that would explain the not returning result form the loop.

  • Nobody (unregistered)

    Here is why not to use lastPathComponent:

    What is the behaviour of lastPathComponent when the full path name ends in a slash?

    The answer is not obvious.

    1. If it is not in Apple's documentation, then the behaviour of getFilename is undocumented if it uses lastPathComponent. And it may change at any moment.

    2. If it is in Apple's documentation, then Apple's behaviour is almost certainly not what is intended by the writer of getFilename (who returns the entire path unprocessed in this case). In any case, the getFilename function (if it uses lastPathComponent) will not be adequately documented unless this non-obvious behaviour is documented in the function itself. Otherwise what happens when this function is ported to some unrelated system in 10 years' time? Whoever does the porting would have to refer to Apple's 10-year-old documentation for lastPathComponent, if it can still be found.

    getFilename may be ugly but at least we can know what it does purely from reading it, and this will continue to be the case forever. There is a lot of application code that is far older than the oldest operating system still in use, and this will always be the case.

  • Puzzl´d (unregistered)

    Hi Nobody.

    But please, throw some light: is the answer in the documentation, or is it not? Are seeing an example of Schrodinger´s Documentation, where the answer both is and is not in the documentation until someone checks it?

  • djingis1 (unregistered)

    Obligatory: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

  • Mike (unregistered) in reply to Greg

    I've also seen that before along with standards dictate that you don't return from inside a try/catch block.

  • Ron Fox (google) in reply to djingis1

    "The Naming of Cats is a difficult matter, It isn't just one of your holiday games; You may think at first I'm as mad as a hatter When I tell you, a cat must have THREE DIFFERENT NAMES. ..."

  • Bill Coleman (unregistered)

    What if the path is separated by colons ":" -- which is normal on a HFS-style path name?

  • asdf (unregistered)

    Why does Remy hate Objective-C that much? Yeah, the syntax is a bit weird, but it's not hard-to-use as he claims in the comment.

  • just me (unregistered) in reply to asdf

    Why does Remy hate Objective-C that much? Yeah, the syntax is a bit weird, but it's not hard-to-use as he claims in the comment.

    Last time I had a serious look at it (admittedly that was maybe 10 years ago), it was every bit as hard to use as he claims in the comment, and then some. A description I once read somewhere, "The safety of C with the convenience of Java", sums it up quite nicely.

  • (nodebb)

    I often find it's much quicker to write path handling code with pure string functions compared to using the library functions. I always find reading code that is using the library functions much easier to read than code which uses pure string functions. The abominations above serve only to reinforce my views.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Puzzl´d

    https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/#//apple_ref/occ/instp/NSString/lastPathComponent

    It's clearly documented to strip all trailing slashes, unless the entire string is just "/". Multiple examples!

    Now, whether or not Apple's documentation will still be accessible in 10 years' time is another question. Some time in the early 2010's, Apple moved the URLs for most/all of their Objective-C reference, without adding redirects. As you'd expect, this broke All Of The Links.

  • LH (unregistered)

    Multiple return points in one function is a code smell. Returning from inside a loop is more difficult to spot when analyizing code.

  • just me (unregistered) in reply to LH

    If that's a problem, consider the possibility that your loop body might be too long.

    Also, I don't really see how a "return" is more difficult to spot than a "break"...

  • Angela Anuszewski (google) in reply to LH

    My customer (to whom I must release source) won't allow multiple return points. You should see some of the eye-rolls I've gotten over the years when I've told the young-ins their code doesn't meet standards.

  • Brian (unregistered) in reply to Angela Anuszewski

    Yeah, but I bet that customer is "special". And they have a lot of rules.

  • bryan986 (unregistered)

    Names starting with underscores are irritating. Whoever started that trend needs to be slapped.

  • Somebody (unregistered) in reply to bryan986

    The only underscore that I see in the article is __strong which I believe is a compiler annotation thing.

  • Mason Wheeler (unregistered) in reply to just me
  • Mason Wheeler (unregistered)

    BTW why is the "login via GitHub" functionality broken and causing a 500 - Internal Server Error when I try to use it?

  • TopTension (unregistered)

    Single exits from functions have their advantages, akthough I am not 100% strict about it. If I can do it easily with s single return without adding too many nested if/else statements, I prefer the single exit point.

    Single exit points are especially useful when you need to do some cleanup like freeing memory, closing a file or leaving a critical section before returning. It's too easy to overlook one return and have your critical section locked forever.

  • just me (unregistered) in reply to TopTension

    Single exit points are an illusion in any language which supports exceptions.

  • (nodebb)

    As long as you have scope-bound resource lifetimes (implemented by many languages, variations include using in C#, RAII in C++, various examples in Lisp) then there's no way to reasonably leak resources, even in the presence of exceptional conditions. Heck, Objective-C includes @finally clauses for their @try, so no excuse on that front. The single-exit rule is at best just silly.

  • Tester (unregistered)

    Another example of how the built-in functions are more often prepared to handle exceptional things is the case where path separator is not '/' but for example ¥.

  • frits (unregistered)

    @finally { //??? }

    return Profit;
    
  • Verisimilidude (unregistered)

    History Lesson: In the late 60's the mathematicians were working on the first attempts to prove code correct. (Of course the code the were working on was written in Fortran and Algol60.) They found that their work was made easier if a routine did returned a single result in place of setting global variables and jumping into the middle of loops. (An early result was disdain for the goto statement.) Lesser lights picked up on these results and declared (without proof) that a single return point was easier to debug and taught this to their students who found it true in Pascal and later those students became PMs and CTOs and forced it on all who toil in enterprisey environments. Of course those who really understood what was being said by these pioneers of CS took the ideas of programming with functions (and reasoning about functions) and created Prolog, Haskell and ML and proof languages like Coq and Z. Returning your result from a loop is no harder to model than short circuited && and || statements but the silliness of a single return statements still lives.

  • Ashley Sheridan (google)

    At least they're using UTF8 letter matches in the regex and not naively using [a-z], which I see all too often from people who should know better

  • LCrawford (unregistered) in reply to Verisimilidude

    Having a single return point is not just an unproven myth - in the days before automatic resource management constructs such as smart pointers and garbage collection, on an early error you'd have to remember to de-allocate any locally allocated memory before returning, as well as closing any files. It made for some weird error conditions in the days before 100% code testing coverage.

    Having a single return point makes it easier to inspect that all necessary cleanup is always performed before finishing.

  • Verisimilidude (unregistered) in reply to LCrawford

    Allocation of process memory and file operations are side effects and should be pushed out of the functions. Monads do this in pure functional languages. As you point out the more mainstream modern languages rely on exit code and finally blocks. If you are writing assembler or C code then I will grant you that you might code your exit block in one place and jump to it from any place in the function. Requiring this as a standard in Java, C#, C++ or Python is TRWTF.

  • DWalker (unregistered)

    "...Python’s super-powered slice operator for splitting the string apart:"

    samp = file[file.find('intFiles')+9:].split("/")[0] fName = file.split("/")[-1]

    Um, I don't see a SLICE operator anywhere. I see SPLIT, but not SLICE.

  • (nodebb) in reply to asdf

    I wrote my iPad app (Coder's Stone) in Objective-C. The brackets were a little weird when I started out, but you get used to them pretty quickly. The main problem I had was the long names for functions in Apple's libraries and also the syntax for defining parameters.

  • (nodebb) in reply to asdf

    I wrote my iPad app (Coder's Stone) in Objective-C. The brackets were a little weird when I started out, but you get used to them pretty quickly. The main problem I had was the long names for functions in Apple's libraries and also the syntax for defining parameters.

  • Verisimilidude (unregistered) in reply to DWalker

    Python's index operation (the square brackets) can be used with a colon in the selection to return a slice. An alternative is to use a call to the slice function explicitly but idomatic Python uses square brackets. https://docs.python.org/2.7/library/functions.html?highlight=slice#slice

  • Robert Hanson (unregistered)

    For the example code, whether the return statement is at the end of the function, or somewhere else, is not the relevant point. What should be obvious, is that this method screams to be rewritten as a recursive function. If one were to do that, the code would be greatly simplified; there would be a single exit point at the end, and you probably could get rid of the try/catch as well. And since it would be tail-recursion, modern compilers would even manage the stack for you so there would not be a risk of stack overflow.

  • Mason Wheeler (unregistered) in reply to Verisimilidude

    Allocation of process memory and file operations are side effects and should be pushed out of the functions. Monads do this in pure functional languages.

    ...and no one uses them.

    There's a lesson in there somewhere.

  • (nodebb) in reply to Ashley Sheridan

    At least they're using UTF8 letter matches in the regex and not naively using [a-z], which I see all too often from people who should know better

    Is that what the \pL is? TIL.

    /^[\pL]+[.']?((-| )[,\pL]+[.]?)$/ for the string tables, bobby query insanity the first Apparently gives back:

    1. [32-38] first
    2. [32-33]

    :wtf:

  • Nobody (unregistered) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    if lastPathComponent is "clearly documented to strip all trailing slashes, unless the entire string is just "/". Multiple examples!" then it is different from the implementation in getFilename and incompatible with it. getFilename does not strip trailing slashes.

  • David (unregistered) in reply to Tester

    "the case where path separator is not '/' but for example ¥." is not a problem when accessing the filesystem. There is no place where U+00A5 is the path separator. There are places where 5C is the path separator, and the system displays 5C (standardly ) as ¥, due to a conflation of ASCII and an almost-ASCII Japanese standard.

  • Axel (unregistered)

    Objective C is to C as spastic colon is to colon.

Leave a comment on “Finding a Path”

Log In or post as a guest

Replying to comment #464855:

« Return to Article