jdrek1

You get points for being the fastest to submit the correct solution to a puzzle part each day. First one gets 100 points, second one 99, and so on down to place 100. So you could get up to 200 points per day if you solve both parts of the puzzle as first one. However unless you can be on your computer when the puzzles unlock (midnight EST (UTC-5)) I wouldn't bother with the global leaderboard, it gets filled within minutes.

Okay I think I understand your core issue. My position is that you do one indent per open scope and those should be done by tabs. Since those usually appear at the beginning of the line there's no problem because tabs behave exactly like you want them to (equal X spaces). It also produces nice boxes, especially in C like languages if I may say so, personally I think Python forcing you to obey this principle is actually a good think to teach people. Can look like this:

  +--------------------------------------+
  |namespace foo                         |
  |{                                     |
  |     +------------------------------+ |
  |[TAB]|void bar(args)                | |
  |[TAB]|{                             | |
  |     |     +-----------------+      | |
  |[TAB]|[TAB]|while (condition)|      | |
  |[TAB]|[TAB]|{                |      | |
  |[TAB]|[TAB]|[TAB]// body     |      | |
  |[TAB]|[TAB]|}                |      | |
  |     |     +-----------------+      | |
  |     |                              | |
  |     |     // and another scope     | |
  |     |     +-----------------+      | |
  |[TAB]|[TAB]|if (condition)   |      | |
  |[TAB]|[TAB]|{                |      | |
  |[TAB]|[TAB]|[TAB]// body     |      | |
  |[TAB]|[TAB]|}                |      | |
  |     |     +-----------------+      | |
  |[TAB]|}                             | |
  |     +------------------------------+ |
  |}                                     |
  +--------------------------------------+

Your problem appears when a new scope does not seeem to start at the beginning of a line, correct? For example like this:

  +--------------------------------------+
  |namespace foo                         |
  |{                                     |
  |     +------------------------------+ |
  |[TAB]|auto bar(args)                | |
  |     | // function body             | |
  |[TAB]|{                             | |
  |[TAB]|[TAB]return baz([args](){     | |
  |[TAB]|[TAB][TAB]// lambda body      | |
  |[TAB]|[TAB]});                      | |
  |[TAB]|}                             | |
  |     +------------------------------+ |
  |}                                     |
  +--------------------------------------+

If you try to draw a rectangle around only the lambda you have to "indent" the body by spaces to make it nicely aligned like this

  +--------------------------------------+
  |namespace foo                         |
  |{                                     |
  |     +------------------------------+ |
  |[TAB]|auto bar(args)                | |
  |[TAB]|{                             | |
  |     |                +----------+  | |
  |[TAB]|[TAB]return baz(|[args](){ |  | |
  |[TAB]|[TAB][TAB]      |     ...  |  | |
  |     |[TAB]           |}         |  | |
  |     |                +----------+  | |
  |     |[TAB]);                       | |
  |[TAB]|}                             | |
  |     +------------------------------+ |
  |}                                     |
  +--------------------------------------+

and someone misguided could have the really bad idea of first wanting to align a box and then doing the indent for the lambda scope:

  +--------------------------------------+
  |namespace foo                         |
  |{                                     |
  |     +------------------------------+ |
  |[TAB]|auto bar(args)                | |
  |[TAB]|{                             | |
  |     |                +----------+  | |
  |[TAB]|[TAB]return baz(|[args](){ |  | |
  |[TAB]|[TAB]           |[TAB]...  |  | |
  |     |[TAB]           |}         |  | |
  |     |                +----------+  | |
  |     |[TAB]);                       | |
  |[TAB]|}                             | |
  |     +------------------------------+ |
  |}                                     |
  +--------------------------------------+

That obviously leads to problems, yes, but that is simply someone who did not understand "tabs for indent, spaces for alignment" then. You should train that person better, it's really not that hard and also there's tools that can easily warn on such things. Banning tabs gets rid of this problem but it also gets rid of the advantage tabs have, namely that the indentation can look differently to many people without causing any VCS problems. And that's worth a lot more than saving a one time 2 minute work of enforcing a check for such things in the VCS for a single person.

> Alignment is desired because it enhances readability.

While that's true I was asking specifically about those examples of yours. What would be the reason to have a weird L shaped comment around the code like that? Right now I can only see two situations in which something is aligned in code, the first one being something like this

    int    foo;
    double a;

because for some reason people like to have variables like that. Personally I don't see why anyone would want to do that but if they want to insert extra spaces they can do that, it's trivial to clang format before the commit and absolutely nobody even has the idea of using tabs there.

The second one are function arguments over multiple lines. Personally again I find it a bit ridiculous that someone absolutely needs to have

  void foo(arg, arg
           arg, arg)
  {
      ...
  }

when

  void foo(
      arg, arg, 
      arg, arg)
  {
      ...
  }

is just as readable and even saves you keystrokes because you can use an indent level for the alignment of the arguments and just have one tab (well two, since it's two lines) there instead of the 9 spaces you otherwise need. But again if they prefer the other style then that's fine, but it's no reason to force them to do the indentation with spaces too. Your example is flawed, you should never mix tabs and spaces like that, tabs never follow spaces. You use tabs to indent to whatever level you're currently on and then if you really want that alignment for whatever reasons you use spaces for the rest.

> Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.

I don't think a clang format commit hook is that hard to enforce. Not to mention that you are enforcing formatting anyway, otherwise you end up with one person using 2 spaces and the other 8. And if you already enforce that then there is no reason to not just enforce using tabs for indentation since they are objectively superior.

> People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.

> The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.

Do you really think that dismissing people's preferences as psychological disorders is a good idea? Especially in a community that likes to customize the shit out of everything? Why shouldn't they be allowed to see the code however they like? That's literally the idea of using tabs, you can see them as 37 spaces if you like but for me it's 4. If you want to do any extra alignment after the indentation then use spaces, sure. But who are you to decide how far right on my screen the body of the loop appears? Tbh if you ask me I find your proposal straightup draconic, you rather ban tabs completely rather than using the available tooling and/or properly training your people to enable everyone to work as they see fit. Yeah sure most people can work with a 8 spaces codebase if forced to but that doesn't mean it's a good idea.

And since you brought up disabilities: I've worked with someone who had only one eye, he didn't do any indentation because otherwise he'd have to constantly move his head around. Set tabwidth to 0 in his editor and you don't need to do any reformatting on commits if you indent using tabs. Force spaces on everyone and he needs to do a reformat all the time.

> (I don't think my editor can do this and don't know of any which can).

I'm not sure I follow why this is necessary. They already act like that, the only tabs not being as wide as X spaces are the ones that follow a non-tab character and at that point you are no longer doing indentation anyway so a tab should not even exist there. Though I don't see a reason to not have this, should be a simple setting in any editor.

I'm curious, why would you ever want to align something like that? I've only ever seen "but it breaks my alignment" as the only argument from the spaces people but so far I have not yet seen a good reason as to why that alignment is desired in the first place. Comments like that seem extremely unlikely to me, comments are for explaining a non-obvious "but why" and that's better in a paragraph above the code, especially if you use tools like doxygen who expect them there.

And in the function example I assume you do it because the args don't 'fit' on one line but then why not just have your editor wrap the line (and optionally indent by one level)? To spot the function name better? Why not use syntax highlighting for that?

And even then just use tabs for indentation and spaces for alignment, what would be the reason to force spaces on everyone else and make them suffer from an indentation width they don't like?

Hm looks like the error is on my side then, good to know it works for others. Thanks, I'll see if I can get it to work somehow!

Did you run into any problems using that layout? I tried using it (also after discovering it on HN) but I could not get around that bug where Windows error sounds appear randomly when alt tabbing.

And why no blockchain?

My apologies, I did not know about that. Why would they deliberately put duplicates in unicode though?

> For example in my keyboard the micro sign (µ; not to be confused with the Greek small letter mu)

The greek letter mu IS the micro sign, where do you think it comes from?

Damn sorry, I hope it gets better for you. In that case I can definitely see how not having to leave the keyboard is of upmost importance.

That's a reason I can get behind. I agree though, most people probably don't need that, but in such cases it's great to have a tool like that available. Thanks!

I don't think your take is wrong. I have yet to see any actual argument from the vim/emacs crowd. I'm genuinely curious about what makes them defend their editor choice that heavily but whenever I ask them for their reasons all I get is a "modal editing is great because modal editing is great".

I can somewhat understand "don't have to touch the mouse" as that's a personal preference for them (even though IDEs have key binds too, I think they blow up that argument way too much) but on anything else they are suspiciously silent. Maybe I have just not met the right people to ask but that's my personal experience. Anyone I know using vim only does it because they either have been using it for 40 years or have been told to use it by someone from the first group and don't know anything else.

I'm curious, what do you want to test? The classic "memorize how to bubblesort" interview questions which so many people complain about because they don't show anything except that someone has prepared? Isn't it better to just look over the code of applicants and check if they are aware of general structures etc?

Obviously some familiarity with algorithms etc is required and it should be checked if that's there, but with tests you can't really test if someone understands the bigger picture and did not just memorize the answer. I know more than enough people who can solve problems just fine but their code is absolutely atrocious and I'd never hire them. Interviews where one can ask them why they write code the way they do are probably far more effective.

Because it imports everything from the std namespace and can lead to name clashes. It also makes it harder to see where symbols come from. If you see `std::vector` you know exactly what it is. If you just see `vector` in a large code base it could be anything. Could be a hand-rolled version of std::vector from prehistoric times or people not trusting the STL for no reason. Could also be a mathematical vector or something for vector graphics or whatever else. That is why people generally always fully specify where things come from, it's not limited to just the STL.

`using namespace X;` is somewhat fine if you limit it to a scope by using it in a source file and ideally only the function body where you use it, in header files it is a really bad idea because then the namespace gets exposed to everything including that header. That can lead to the compiler calling the wrong function and you might not even notice it.

One should probably point out that the library/readme is not the only suspicious thing. The author often has huge problems with terminology and/or communication in general. He routinely confuses output with formatting, which might explain some of the "benchmark results".

[1] https://www.reddit.com/r/cpp/comments/dc5t1n/reply_to_herb_s...

[2] https://www.reddit.com/r/cpp_questions/comments/efuemt/c_wit...

[3] https://www.reddit.com/r/cpp_questions/comments/f7zgat/why_d...

I mean, why not? Doesn't even have to be a full domain name, even just assigning everyone their individual IPv6 address would work.