I'm going to disagree with you there. It's a convention that comments refer to the following lines of code, not above. Reading from top to bottom or bottom to top has nothing to do with this. A better way IMO is to disambiguate what specifically "this" refers to in the comment.

> It's a convention that comments refer to the following lines of code, not above.

Oh, an "argument" on the base of "We have always done it that way". So we don't have even an argument here.

And no, this nonsensical "convention" is not everywhere followed as people realized that code should be written in the most readable way possible.

I know a lot of human langues that are read form top to bottom. I don't know even one where you read bottom to top…

Jumping around mentality in code is a sure way to make the code hard to understand. Ever heard the reason behind why `goto` is considered bad?

Ever seen Python doc-strings?

Did you write your comment under my comment or did you write it above? Why is this so?

Also writing comments above leads very often to the kind of comments that describe what the following code does. Which is the most wrong type of comments, like it was said here not only once.

Comments below lead OTOH naturally to comments that describe why the code was written like it was written.

There may be exceptions for the rule and cases where it make sense to have something like a "heading" comment. But this cases are very rare.

If you actually think about it almost all (good!) comments make much more sense below the code that is commented as this is the natural way how to write. Just look how this site here is structured. And it's all about comments!

Bottom line: Use your own brain! Don't do things because someone told you "We have always done it that way"!

Also a good point.

Thanks!

So maybe like so:

        showThrobber()
        // The reason for the asyncAfter(), is that we need to give the throbber time to show up.
        DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + DispatchTimeInterval.milliseconds(20)) {

I tend to like to put comments to the right of the lines, but not if they are long ones.

I don’t usually like to put stuff just under opening braces, because I feel that it can sometimes obscure the fact that a new context was opened.

Indentation is important. Back when I programmed C++, I used Whitesmiths indentation, but I changed to K&R, when I started writing Swift. With Whitesmiths, you can put a long comment, just above the context opening, and the comment can apply to just the context, and not the opening statement. This established a habit of having comments apply to the line below.

Here's an example of the same kind of thing, in another part of the same codebase:

    if userFallbackRaw == (inError! as NSError).code {   // Fallback means that we will use the password, so we nuke the stored password.
        #if DEBUG
            print("Biometric fallback.")
        #endif
        // Wow. This is one hell of a kludge, but it works.
        // There's a "feature" in iOS, where the Touch/FaceID callback is triggered out of sync with the main queue (slightly before the next run cycle, I guess).
        // If we immediately set the password field as first responder in this callback, then it gets selected, but the keyboard doesn't come up.
        // This 'orrible, 'orrible hack tells iOS to select the field after the handler for this Touch/FaceID has had time to wrap up.
        DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + DispatchTimeInterval.milliseconds(20)) {
            self._bioHazard = true
            self._selectedPassword = ""
            self.emailAddressTextField?.text = self._selectedLogin
            self.passwordTextField?.text = ""
            self.isThrobberShown = false
            self.passwordTextField?.becomeFirstResponder()
        }

Good point.

Thanks!