Hum. I haven't been here for a long time and quite interesting discussions happened.

With something like 20ish years of vim scripting, I've spent some time on the topic of script writing and maintenance.

I've "started" ("ended-up a long time ago" would be more correct) with a vim library I use in almost all other scripts I write, hence my stance on "VAM or vim-flavor are the only two plugin managers that deserve attention -- as they are the only ones that support dependencies".

In my library plugin I've added a logging framework and a Design By Contract framework, plus some other blog-li…

The OO article is a very specific part for when I think it would be simpler with objects.
What really defines my _style_ is that I've quickly spent time into several distinct and unrelated plugins and I needed the same helper functions in several plugins. That's when I started to define "library plugin files" which were stored either in `plugin/` or in `macros/`. Then came Vim7, and autoload plugins had a great impact -- as important as Vim6 which introduced ftplugins (yeah I was emulating ftplugins in Vim 5.x at the time: http://hermitte.free.fr/vim/ftplugin.php#ftplugin)

Then, there is my plugin maintenance workflow. I'd have a lot to say as well. And I think the most important parts are how I track errors (I have my owns solutions for navigating plugins, reloading them... but other exist as well). All is done through several features of my main library plugin (logs, DbC, and `:WTF`) and my vim-UT plugin. While I've described the features, I haven't really described the actual workflow.
More over using a complex logging framework in a new and simple plugin can seem overkill at first. Yet, as the plugin grows in complexity, the logs become more and more impo…