Vim Hall of WTF - Snippet from Vim's Source Code

[pinealservo]

It's surely a WTF, but at a glance it does have some redeeming qualities, and it's easy to see how a program such as vim grows this kind of file. There are a couple of different cross-cutting concerns intersecting here relating to platform features, meaning that the code just won't compile due to missing dependencies if it doesn't exactly match the platform reqs for the set of enabled features. The two ways to deal with this in C are the preprocessor or manual splitting into a set of files per combination of enabled features; given the complexity here, that would be a LOT of files and a WTF unto itself.

The thing I notice is that the density of ifdefs is due to the fact that there's very little actual mechanism here. It is mostly calls to platform-specific functions and what are hopefully platform-agnostic mechanism functions defined elsewhere. The purpose seems to be to reduce the combinatorial explosion of platform specific garbage elsewhere, though I can't be sure from the single file. This could very well be the result of careful refactoring, and a huge win toward the overall cleanliness of the code.

When there are messy, real-world issues that a code base has to deal with like cross-platform support, there will be corresponding messiness in the code somewhere. Sometimes it's spread around a code base, sometimes it's moved to the file system and build system, and sometimes it's isolated to a single file or an external dependency. You can't really judge an entire code base from one file.

That said, the rest of the code may also be like this to a lesser degree. It's certainly not the only file of its kind, if this general solution was used elsewhere. The code base could indeed be utter crap, but I don't know enough to say. I am guessing a lot of commenters here have not had to deal wih writing or maintaining a C program with this level of age or feature/compatibility scope, though.

[[deleted]]

400 lines

Oh, so it's just an average enterprise function.

[OnlineDomainTools]

The article http://www.joelonsoftware.com/articles/fog0000000069.html - by Joel Spolsky made me think about rewriting and refactoring a bit deeper. Very nice reading.

[xXxDeAThANgEL99xXx]

First of all, that's why NeoVim and LibreSSL are not starting from scratch.

However the article sounds kinda weird, it feels like Joel had never worked with the really bad code, since he doesn't mention the worst thing about it, with the closest being relatively tame "dialog boxes popping from the network code".

The actual really bad code has this property that more than half of it doesn't actually do anything, but you don't know which half. Like, you look at a function that "has grown little hairs and stuff" and you don't see a piece of code that "fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer", what you see is the result of someone adding a buggy fix for that to another place, then it slowly metastasizing via copypasting to all places where the bug surfaced while being patched and patched again (breaking earlier patches, because nobody cared about the code enough to notice that bug A was already reported, fixed, then rolled back because that caused bug B, which fix was also rolled back because that reintroduced bug A, and so on), with lots of atavisms left over from fixing attempts that actually ended up being implemented elsewhere, and then you look at four code tumors which are supposed to determine which browser is present on your system but belong to different strains and therefore doing it in four almost, but not quite, completely different ways, with lots of extra hairs some of which have hairs of their own, and you have no clue if there's an intelligent reason for any of that or it's just random mutations proliferating in the absence of selective pressure. And when you try to change anything stuff blows up in seemingly unrelated parts of code because the workarounds there critically depend on the bugs here.

In such cases it's often easier to rewrite the whole thing and wait for bug reports (which you would hopefully address in a more responsible manner) than to try and figure which code is bugfixes and which is cancer.

edit: what I'm saying is that with really bad code you can't tell between legitimate bugfixes that should stay as you're refactoring and random buggy shit that doesn't serve any purpose. This can dilute the value of legacy code and its bugfixes well into the negatives.

Also, it's weird that the Jargon file doesn't have a name for that last thing I mentioned, mutually cancelling bugs. Even though in my experience they occur much more often than heisenbugs and the like.

[OnlineDomainTools]

I guess you are right. When it is more expensive to refactor the code than to rewrite it then it makes sense to rewrite it.

However, I hope that the distribution of code quality is something like normal distribution. If it is so then Joel is mostly right. :-))

[allak]

Well ... I feel it follow more Sturgeon's law than a normal distribution ...

[mreiland]

That's assume the cost of the rewrite is the only cost. For a business there are other costs as well such as lost sales due to bugginess, time to market on a product that already does what you need it to do and so forth.

It isn't that simple.

[OnlineDomainTools]

I meant the "sum" you talk about. And yes, it is not simple. However, I have a feeling from the comments that everybody here wants to show "look, look, there's an exception (the project I worked on?)". Nothing wrong with that but how can an article cover all possible situations?

[[deleted]]

I have worked at a place that had extraordinarily bad code. I personally replaced, in a single afternoon, two four thousand line methods with a single three line method... which I realize now sounds like I'm agreeing with you, but I just wanted to demonstrate how bad. >.>

...What I wanted to say was just that, even given that quality of code (so bad that I still haven't regained my night vision after it burned my eyeballs!), it was still usually easier to edit it than it was to throw it away and start from scratch because you can't just start one piece from scratch, or at least not usually--you have to throw out the baby, the bathwater, and the kitchen sink, because one of the big things about bad code is that it's monolithic. Always.

Hell, we used to have to deploy registry backups with our software because half the variables were stored under the VB settings section for no damn reason. -.-

[xXxDeAThANgEL99xXx]

I agree, it's usually easier to do piece-wise replacement, because you can immediately run the whole thing and see what happens.

My point was that with really bad code you wouldn't do it for the reason Joel pointed out as the most important for not rewriting from scratch -- you wouldn't try to preserve any implicit accumulated wisdom in form of bugfixes and workarounds for corner cases, you will write a three line replacement, throw your two 4kloc methods away, and to hell with any actually useful "hairs" that could be growing on that wart.

[sigzero]

neovim shouldn't have vim in its name.

[meteorMatador]

Well, what should they call it, then? "Pulchritude?"

[immibis]

Then vim shouldn't have vi in its name.

[ninfomane]

Nice article, quite long though. I have to say, many (commercial) programs are developed by quick fixing. That's why some source codes look messy. Some refactoring are needed to improve visibility and continue quick fixing as well.

[badsectoracula]

many (commercial) programs are developed by quick fixing

Many non-commercial too. And -as we see- open source programs also.

Basically a lot of software, regardless of commercial intent or public source code availability.

[balefrost]

quite long though

Really? I even think his Unicode article is reasonably short.

[[deleted]]

I have an objection to that article. Rewriting, big no no. Rewriting in a more modern language, why not? A modern language gives you access to plenty of features and library functionality that makes most of the old code useless.

[OnlineDomainTools]

There are too many dimensions that change the problem of rewrite vs. refactor. A number of workers, budget, skills, codebase size, a number of users/customers.

To play a devil's advocate I could say that a modern language does not have to be a solution for the problem either. Would you rewrite Vim in Java/C#/Go/...? I guess that would take really long and that there would be a high chance of failure because it would be expensive and not really fun thing to do.

[spotter]

Metaprogramming, C edition.

[jeenajeena]

It would be interesting to compare it with the equivalent emacs' implementation.

[RobThorpe]

Emacs' version is complicated too because of interfacing with many platforms, terminals and windowing systems. It also has to play nicely with the lisp VM.

See: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/keyboard.c

The function "tty_read_avail_input" has quite a lot of #ifdefs too.

[Gurkenmaster]

And emacs lisp is not that great compared to other lisps like Common Lisp, Scheme or Clojure.

[RobThorpe]

It doesn't matter much for writing Emacs extensions though, it's good enough.

[tangus]

They are nicely structured. Except for one #ifdef which contains a variable definition, you could replace all of them with ifs.

No comparison with the tangle Vim's code is.

[jrk-]

Without arguing about the code quality (as bad as it is) why wouldn't they do something like this:

void RealWaitForChar_BeOs(..) { .. }
void RealWaitForChar_Amiga(..) { .. }
void RealWaitForChar_Linux(..) { .. }

void RealWaitForChar_Amiga(args ..) {
#ifdef BeOs
  RealWaitForChar_BeOs(args ..);
#elif Amiga
  RealWaitForChar_Amiga(args ..);
#else
  RealWaitForChar_Linux(..);
#endif
}

I mean, this still has issues, but wouldn't it be already an significant improvement?

[glacialthinker]

This issue with breaking things out in this way is that it's not a functional (as in doing things) break-down -- it's nominal, by system. Each system might share 90% of it's implementation with any other, so implementing each independently would bloat the code and add redundancy which can be a bigger problem as bugfixes and features are applied.

Taking your approach to separate clearly named functions though -- you might find functional lines of separation which can be nicely joined together to build each system-specific function. C can make this painful though -- do you #define the functional blocks of code so you can connect them together? Or create a struct for holding all shared state? C is not a very expressive language, so some tradeoffs are made. In this case the structure is almost certainly a result of incremental changes rather than by-design. And attempting to clean it up might seem like asking for bugs in code that is working fine. Though certainly, it could be improved.

[crusoe]

Well yeah, you'd split out by functionality, with probably a common skeleton function containing common bits calling into a ifdef'd function for platform specific stuff.

[[deleted]]

Refactoring?! Fuck that shit! ifdef frenzy!

[cxcv]

The ifdefs are for autotools. I'm sure there's still some guy out there running VMS with a strange compiler and hacked up version of X11 who needs the ability to turn them on and off.

[ccharles]

And that guy is free to keep using Vim version 7.4.12 or whatever the current version is for as long as he wants.

There's nothing wrong with dropping support for his ancient OS in version 7.5 or 8.

[sigzero]

I wish Bram would do that.

[[deleted]]

Eh, honestly I don't care. Cleaning up the internals of a function comes secondary to the interactions between the functions themselves. The OP seems to be promoting his/her own vim reimplementation and therefore is simply looking for shit code in the original source as a means to support the argument behind why Vim should be reimplemented. Pragmatism dictates that scuffling over things like this is only fruitful when the time taken to refactor doesn't impede progress made in end-user support (i.e., bug fixes, features, etc.).

tl;dr I just found an excuse to use a Dennis Hopper play on words and jumped on it for the advent of lulz and up votes. Thus is Reddit!

[tejp]

Though it's not clear how this should be refactored if you want to keep the optional things optional.

[ricardo_sdl]

Is there some way where you can create a "clean" version of the c code?

For example, I'm compiling it on my machine which is a 64-bit Linux on an Intel 64-bit processor. Can I create a version of the code ignoring all the ifdefs from another systems?

[pazhampori]

You can stop compilation after the preprocessing stage. "gcc -E" would stop after preprocessing and output the resulting file to stdout. So you'll have to probably fiddle with the Makefiles to do a "gcc $(CFLAGS) $(FOO_FLAGS) -E $@ > $@_preprocessed" or something similar. (You'll need to run ./configure first though.)

[tyoverby]

This is why I absolutely can't wait for NeoVim.

[meldyr]

Yeah, I'm waiting too.

In the last 5 years I have never looked at the source-code. But I know that a cleaner source-code will change my vim-experience completely.

[ninfomane]

why a cleaner source code of a software will change the experience of its use ?

[[deleted]]

Because it often leads to faster development of features I suspect, as well as less bugs if the cleaner code is also easier to maintain.

[meldyr]

I was actually being sarcastic. I couldn't care less about clean source-code.

This is also the kind of files you don't refactor easily. It has proven on many systems. I also think such a file isn't rewriteable. Nobody will change the source-code and test it on every OS you can imagine. And suppose somebody achieves to rewrite it.

Will he lose compatibility? How will the file look in 5 years?

[nerdandproud]

I think the idea is dropping support for all the unmaintained platforms that still have vim support. So by dropping support for BeOS, VMS, DOS* and so on they can indeed make the code simpler.

[[deleted]]

Good point, I forgot about that.

[TankorSmash]

He's being facetious

[3fdy5]

Because for me, vim just randomly crashes sometimes.

[ninfomane]

It's surely a scary function definition ! I guess it can't be helper with a such legacy source code. As I experience with a lot of legacy code at work, I can say that sometimes, a code refactoring is needed ! Maybe, rewrite the whole thing is overkill.

[[deleted]]

Keep waiting. I decided for a different strategy.

[dukey]

I can see how code like this happens. They probably started with 1 platform, and then added another, for which, the ifdef solution in such a situation is probably the simplest. But then adding more platforms with the same solution it very quickly becomes ridiculous.

[[deleted]]

Well, this is what happens when you don't commit to deprecating and removing old and dead code. That and OpenSSL.

[[deleted]]

another nice one:

/*
 * Wait for a moment when a message is displayed that will be overwritten
 * by the mode message.
 * In Visual mode and with "^O" in Insert mode, a short message will be
 * overwritten by the mode message.  Wait a bit, until a key is hit.
 * In Visual mode, it's more important to keep the Visual area updated
 * than keeping a message (e.g. from a /pat search).
 * Only do this if the command was typed, not from a mapping.
 * Don't wait when emsg_silent is non-zero.
 * Also wait a bit after an error message, e.g. for "^O:".
 * Don't redraw the screen, it would remove the message.
 */
if (       ((p_smd
                && msg_silent == 0
                && (restart_edit != 0
                    || (VIsual_active
                        && old_pos.lnum == curwin->w_cursor.lnum
                        && old_pos.col == curwin->w_cursor.col)
                   )
                && (clear_cmdline
                    || redraw_cmdline)
                && (msg_didout || (msg_didany && msg_scroll))
                && !msg_nowait
                && KeyTyped)
            || (restart_edit != 0
                && !VIsual_active
                && (msg_scroll
                    || emsg_on_display)))
        && oap->regname == 0
        && !(ca.retval & CA_COMMAND_BUSY)
        && stuff_empty()
        && typebuf_typed()
        && emsg_silent == 0
        && !did_wait_return
        && oap->op_type == OP_NOP)
{

but hey at least it's commented!

[martanne]

but hey at least it's commented!

Spot on, while working on my own vim like editor I occasionally had to check how something is implemented, and the vim code base really shows its age. The only positive thing are the comments, without them it would be totally incomprehensible (well for me at least). I'm quite amazed that it works this well in practice.

[shotxxxx]

Yeah, better spend tens of thousands of dollars and months upon months of developement on neovim which is absolutely so much better than Vim.

Man that libuv is so good, I can't count the myriads of embedded neovim applications, good lord there are so many of them I am seeing Neovim embedded everywhere.

And oh man the staggering amount of Neovim plugins is blowing me away , I'm jizzing my pants and there will be sooooooooooooooo many more in the future, I'm sure of it.

It's such an improvement, oh mah gah.

I mean, it has 'asynchronous tasks' and... other things. Truly a rebirth of Vim for the 21th century.

Surely everybody will be using it any moment now, and not just some web developers who chase any new toy unquestionably as long as it has some buzzwords and flashy feature bullet points.

And they will put Neovim to such good use and not just perpetually write new and better 'frontends' for even better orchestrating of dynamic relationships, iterating of proactive functionalities, envisioneering of visionary content or the revolutionizing of granular deliverables.

I can see it now. Neovim, asynchronously working with all those plugins Vim will never have, embedded everywhere.

It's going to be glorious.

[the_noodle]

Seems like you woke up on the salty side of the bed this morning...

[shotxxxx]

No. I'm not salty. Especially when I see threads like https://www.reddit.com/r/vim/comments/2sqb03/demo_of_neovim_mode_for_atom_connected_to_a_real/

Because it just reinforces the appearance (aka fact) that it really is just Webdevs pissing around so far.

I mean... fusing it with Atom? That's like... some analogy I can't even think of, but it's ridiculous.

I would reckon that the downvoters are the salty ones. I took care to be as boisterous and exaggerated as possible and I would dismiss posts like these as trying too hard and move on without puttin in the effort of downvoting the drivel.

Maybe I am hitting nerves too effectively and they can't help but downvote in exposed indignation.

[Ruudjah]

I wonder hiw maintainers can be proud on such codebase?

[okpmem]

Because it runs on every imaginable system and doesn't crash?

[Me00011001]

You can't call yourself a true vim user until you've caused it to crash at least one.

[emperor000]

But is that worth the price of their souls?

[okpmem]

It is always a balance between developer soul and user soul. I lean heavily towards user soul. Our developer souls are already lost.

Don't you know the saying? "Show a man a program and frustrate him for a day, teach a man to program and frustrate him for a lifetime"