[Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator

[Dennis Grant]

> I think many of us who are working on the periphery with vtigercrm
have
> pet peeves about the formatted representation of the source code.

I am actually fairly agnostic when it comes to code FORMAT. I think it's
possible to waste a great deal of heat & light arguing over things like:

if ($foo) {

	bar;
}

vice 

if ($foo)
{
	bar;
}

vice

if ($foo) { bar; }

I really don't care one way or another, and attempting to force people
into an alien code format just for the sake of uniformity is really not
worth the effort. It's a freakin' if statement testing if $foo is set
and if it is, it executes bar - that's what matters.

I don't even care if the database access API (for example) is the same
everywhere - as long as I can figure out what is going on, I don't
particularly care about HOW you do it.

I'm a big boy, and I've written and maintained a ton of code. I can
adopt.

What I DO care about is that code is commented AS IT IS WRITTEN - not
after the fact, but as it goes into the code. I, as an integrator, need
to know how the code functions so I can quickly track down bugs, find
where features reside so I can modify them, and identify places to hook
into for integration.

I need to know WHY something is the way it is, and the only way to do
that is through comments.

> No few persons (rightly) want to clean up a fraction of the code
> when new checkins aren't guaranteed follow the same standards.

I (mostly) disagree - every comment is worth its weight (figuratively
speaking) in gold. I'd love it if somebody went through and commented
the entire codebase, but I understand that's a lot of work - and while I
think the dividends that pays are big enough to make the pain
worthwhile, I also understand that it's not very sexy and so not likely
to happen without somebody explicitly funding it.

(Hell, fund ME, and I'LL do it)

But I **DO** think that we can at least stop the bleeding by requiring
that all NEW code be properly commented. It takes a miniscule amount of
effort on the part of the coder and the check-in authority, and it pays
such enormous dividends for later maintenance that we really cannot
afford NOT to do it.

> keep posting patches to the trac please...
> the people managing the 4.x branch have been very responsive and are
> doing a good job...

I have submitted a variety of patches to a variety of places, including
this list, and to the best of my knowledge, not a single patch has made
it into the core.

Some of this may be my fault, and as I mentioned in my first message, I
intend to revamp my own code maintenance process to operate more like a
private fork of the Linux kernel, such that I can generate actual diff
patches, with the intent of making the incorporation of my changes into
the core (when it applies - it doesn't always have universal utility)
easier.

> There was a point in this project where you could come along, see a
> project with a fairly vibrant community forming, an interesting
product
> being developed and a complete lack of direction and management.  This
> type of environment is ripe for internal forks and the fact that the
> project didn't fork into a new OSS project is nothing short of a
miracle
> (seriously!).

Actually, I think with VTiger you are going to see a lot of private
forks, because individual businesses have their own needs and wants that
are supersets of core VTiger functionality that simply don't apply to
other businesses.

My life is easier the smaller the delta is between the vanilla VTiger
core and my own fork, so I intend to try and get as many of my changes
put into the V5x core as possible - but the bottom line is that there
will be things that my management want in our CRM that nobody else in
the world will want, and that's fine.

> Stand behind the OSS project in all
> it's glory and be at the mercy of a project with no direction or
leadership, or fork and be in charge of their own destiny. 

I literally had no choice. I was directed to make the CRM do certain
things (after all, I have the source code) and "it doesn't do that out
of the box" was NOT an acceptable answer. Even "that's coming in the
next version of the CRM" is increasingly hard to justify, given how long
it has taken for 5.0 to solidify.

Some of the things I have done are really very pretty. Others are
horrible, horrible hacks (my version supports localized currencies, with
exchange rates, but you don't want to know how....)

Other changes are less obvious. For example, I was required to modify
the Quote engine so that it preserved the order that products were added
to a quote and printed them out accordingly - totally cosmetic, but our
sales guys had a valid need for that to happen, so I did it.

 
> It really comes down to options 2 and 3, and who wants to double all
> their work when you know damn well that 4.x is going to be abandoned
now
> that 5.x shows the promise it does.  And I mean that with absolutely
no
> disrespect for the people working hard on maintaining 4.x for the
> community. 

Bingo. As far as I am concerned, 4.x is a dead tree being maintained
only as long as necessary to get 5.x established, after which it will be
dropped.

But the habits that NEED to be carried into 5.x MUST be established NOW.

Comment your code.

Every IF has an ELSE - even if that ELSE should never ever execute.

Simple simple simple; but yet they pay enormous dividends later on.

DG