In my previous post, I wrote about a plugin for switching between header and source files (with the support for private classes) for C and C++.

The plugin has evolved for the last two days. It gained another mode, which will also be usable outside of the C/C++ world.

• Full mode - Finding related files based on the words in the file’s name

If you use the CamelCase, or the snake_case naming scheme for your files, the plugin will extract the words from the current file’s name and search (using the find command) for the files that have any of those words in their names.

For example, for ResourceActor.scala, it will return:

ResourceTable.scala ResourceService.scala SomethingElseActor.scala

It is still available at github.com/ivan-cukic/vim-ctrlp-switcher

Hope somebody finds it useful. Everyone is encouraged to contribute or star the project.

Update: continuation of the story: “Even better file switching for Vim”

I’ve been using the vim-fswitch plugin for switching between .h and .cpp files for a long time now. The thing I was really missing was the inability to switch to private headers and implementations (filename_p.h and filename_p.cpp)

Recently, I discovered the (more than awesome) CtrlP plugin. I am not going to explain here what it is - I strongly advise you to check it out!

I’ve written a small extension for it which provides the header/source/private files switcher.

One of my favourite C++11 features are lambdas.

The syntax is a bit cumbersome, but it was the best approach the committee could take without creating a new sub-language. Every part of the syntax has a reason for why it exists.

But, it still is a bit ugly, and can influence readability of the surrounding code quite a bit.

The thing that annoys me the most is the lambda head - the capture block and the arguments it takes. Those are very important when writing the code, but not (that much) when reading it.

My solution for this? The conceal feature of Vim.

The good thing about lambdas is that they are (meant to) be used as local anonymous functions. That means that, while reading other parts of the code, you don’t actually need to know what the lambda is capturing, nor which are its arguments. So, it doesn’t hurt to hide them, right?

Naturally, when you want to edit the lambda head, Vim shows the actual contents of line, and not just some strange Greek symbol. :)

This also lowers the desire to use the potentially problematic [&] and [=] as the capture block, instead of explicitly capturing the variables that you need.

Edit: The code to achieve this:

.vimrc:
    set conceallevel=1
.vim/after/syntax/cpp/cpp.vim
    syn match cpp11_lambda "[[a-zA-Z0-9&= ,]*] *(.*)( *{)\@=" conceal cchar=λ
    syn match cpp11_lambda "[[a-zA-Z0-9&= ,]*]( *{)\@=" conceal cchar=λ

If you haven’t seen the previous post, I’ve posted a question of what style would you prefer (I’ve simplified it a bit here, for the original, go for the link above):

(A)                        | (B)
                           |
if (ratio < 1.5) {         | result = (ratio < 1.5) ? 1.0 :
    result = 1.0;          |          (ratio < 2.0) ? 1.5 :
} else if (ratio < 2.0) {  |          (ratio < 3.0) ? 3.0 :
    result = 1.5;          |          /* otherwise */ ratio;
} else if (ratio < 2.5) {  |
    result = 2.0;          |
} else if (ratio < 3.0) {  |
    result = 3.0;          |
} else {                   |
    result = ratio;        |
}

As expected, people are split into two similarly sized groups. It is a matter of style after all.

Neither of these is better, but they both have their pros and cons. Lets see what we have collected so far.

Firstly, lets deal with the elephants in the room:

- Is this an academic question? (as suggested by krake)

Yes and no. Yes, because it is not really that important - people will continue using what they used before. No, because it might influence the different aspects of the resulting code. (see below)

- You can use if-return format: (suggested by cyber_fusion)

if (...) return ...;
if (...) return ...;
...

This seems to be a popular variant of (A) when the purpose of the result variable is to be returned from the function we’re in (as it was the case in the original post). It does not work in other cases.

While it is a good approach (and preferred by a significant number of people), there was one statement for it, that is not correct - (Alex) “it shows structure, it will not execute if statements after a successful one”. All the proposals behave the same - neither executes statements after the first successful one.

The issue some people pointed out is the lack of braces for the if body which is frowned upon by a significant number of coding styles used across the world. If somebody questions why would missing braces would ever be a problem, just search for the ‘apple goto fail’. When you add braces, the solution stops being as visually attractive.

Now, we can start with the reasons people wrote for one or the other. In no particular order, to avoid the trap of actually counting pros and cons.

(shamaz) The big difference here is that the 2nd solution is ONE statement. This means that it’s less simple to debug : you won’t see which branch is chosen (similar comment by Morten)

It is a single statement, but it has multiple sequence points[↗] (or whatever they are called in the new standard). The same sequence points an if/else construct does. So it will show up (tested in gcc+gdb1) as separate steps while debugging2. You will be able to see where you left the statement.

Edit: 1 clang does not create the same debugging info, so it does treat it as one execution step.

2 It has a big uglier debugging output, but still is quite usable.

(Lihnell) I’d like to add that putting the else in a comment for readability is a clear indicator that the language used is not suitable to the person using it

I do agree. It essentially boils down to the fact that ?: syntax (for this) is not something people are used to. So adding ‘else’ or ‘otherwise’ is a nice way to make it more readable.

(konqoro) I guess it was how we were told to better understand the if-else statements.

There were a few similar comments to this one.

Yes, if-else approach is ubiquitous, and therefore understandable by everyone. IMO, it is the strongest reason for going for it - people are not used to (B) even if (Jeff) “the notation fades into the background, and the structure of the actual operation pops out”.

(dhardy) I find the second much easier to read. My preferences are (a) avoid re-assigning variables

Thanks to some pure functional languages like haskell, the concept of immutability started to spread out to other paradigms. The second approach is also usable in C++11 constexpr functions, while the first one will be allowed in C++14.

One of the approaches to make the result variable const for the (A) variant would be to use lambda-initialization, thus localising the mutable variable inside the lambda. Like:

const double result = [] { ... }();

(Alex Elsayed) I doubt you care overmuch, but PHP will not do what you expect on the second one

You are right that I do not. But, this is a useful information for the future - if I get to hack on some PHP code. Thanks!

(shamaz) For the 2nd solution, if someone try to format your code automatically with his IDE, it may become hard to read.

Yes, unfortunately. I’ve tested it with clang-format and it essentially killed it. I guess if it became a common idiom, formatters would learn to deal with it. :)

Epilogue:

Personally, I prefer the second option although I don’t use it that often mainly because it is not that common and people are not used to it.

I do prefer it on the technical grounds, though. It is perfect for const initialization / constexpr functions, the syntax stops you making code-evolution mistakes similar to the ‘goto fail’, and different mistakes that the original code (which inspired me to write this) had. (the original code was posted for half an hour in the previous post, but I decided to edit it to show only the styling differences, without other issues)

This is a excerpt from a real project, just with variables renamed.

EDIT: * I’ve removed the issues from the original code so that this can be a real style vote, without sidetracking the readers.

Although, by fixing the code, I removed one of the things that I think the advantage of the second one is - it is much harder to make errors and dead code._

const qreal ratio = someFunction();

if (ratio < 1.5) {
    result = multiplier;
} else if (ratio < 2.0) {
    result = multiplier * 1.5;
} else if (ratio < 2.5) {
    result = multiplier * 2.0;
} else if (ratio < 3.0) {
    result = multiplier * 3.0;
} else {
    result = multiplier * ratio;
}

return result;

This was the usual imperative code that you’d find almost everywhere. And this is the alternative (functional) way of doing the same:

const qreal ratio = someFunction();

return multiplier * (
    (ratio < 1.5) ? 1.0 :
    (ratio < 2.0) ? 1.5 :
    (ratio < 2.5) ? 2.0 :
    (ratio < 3.0) ? 3.0 :
    /* else */      ratio
);

The second one is kinda what you’d do in maths:

.
       /  1.0     x < 1.5
       |  1.5     1.5 ≤ x < 2.0
f(x) = <  2.0     2.0 ≤ x < 2.5
       |  3.0     2.5 ≤ x < 3.0
       \  x       otherwise

What do you find more readable?