<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body >I take all your comments with eyes closed.
<br>Kindly expect the changes asap. Please do refer to my prev mail.
<br>Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless.
<br>So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now.
<br>
<br>The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible.
<br>
<br>Richie<br><br><br><br><br>---- Dennis Grant<dgrant@accuratetechnologies.com> wrote ---- <br><br><blockquote style='border-left: 2px solid #0000FF; padding: 6px;'><html>
<xbody>
<br><br>> I think many of us who are working on the periphery with vtigercrm<br>have<br>> pet peeves about the formatted representation of the source code.<br><br>I am actually fairly agnostic when it comes to code FORMAT. I think it's<br>possible to waste a great deal of heat & light arguing over things like:<br><br>if ($foo) {<br><br> bar;<br>}<br><br>vice <br><br>if ($foo)<br>{<br> bar;<br>}<br><br>vice<br><br>if ($foo) { bar; }<br><br>I really don't care one way or another, and attempting to force people<br>into an alien code format just for the sake of uniformity is really not<br>worth the effort. It's a freakin' if statement testing if $foo is set<br>and if it is, it executes bar - that's what matters.<br><br>I don't even care if the database access API (for example) is the same<br>everywhere - as long as I can figure out what is going on, I don't<br>particularly care about HOW you do it.<br><br>I'm a big boy, and I've written and maintained a ton of code. I can<br>adopt.<br><br>What I DO care about is that code is commented AS IT IS WRITTEN - not<br>after the fact, but as it goes into the code. I, as an integrator, need<br>to know how the code functions so I can quickly track down bugs, find<br>where features reside so I can modify them, and identify places to hook<br>into for integration.<br><br>I need to know WHY something is the way it is, and the only way to do<br>that is through comments.<br><br>> No few persons (rightly) want to clean up a fraction of the code<br>> when new checkins aren't guaranteed follow the same standards.<br><br>I (mostly) disagree - every comment is worth its weight (figuratively<br>speaking) in gold. I'd love it if somebody went through and commented<br>the entire codebase, but I understand that's a lot of work - and while I<br>think the dividends that pays are big enough to make the pain<br>worthwhile, I also understand that it's not very sexy and so not likely<br>to happen without somebody explicitly funding it.<br><br>(Hell, fund ME, and I'LL do it)<br><br>But I **DO** think that we can at least stop the bleeding by requiring<br>that all NEW code be properly commented. It takes a miniscule amount of<br>effort on the part of the coder and the check-in authority, and it pays<br>such enormous dividends for later maintenance that we really cannot<br>afford NOT to do it.<br><br>> keep posting patches to the trac please...<br>> the people managing the 4.x branch have been very responsive and are<br>> doing a good job...<br><br>I have submitted a variety of patches to a variety of places, including<br>this list, and to the best of my knowledge, not a single patch has made<br>it into the core.<br><br>Some of this may be my fault, and as I mentioned in my first message, I<br>intend to revamp my own code maintenance process to operate more like a<br>private fork of the Linux kernel, such that I can generate actual diff<br>patches, with the intent of making the incorporation of my changes into<br>the core (when it applies - it doesn't always have universal utility)<br>easier.<br><br>> There was a point in this project where you could come along, see a<br>> project with a fairly vibrant community forming, an interesting<br>product<br>> being developed and a complete lack of direction and management. This<br>> type of environment is ripe for internal forks and the fact that the<br>> project didn't fork into a new OSS project is nothing short of a<br>miracle<br>> (seriously!).<br><br>Actually, I think with VTiger you are going to see a lot of private<br>forks, because individual businesses have their own needs and wants that<br>are supersets of core VTiger functionality that simply don't apply to<br>other businesses.<br><br>My life is easier the smaller the delta is between the vanilla VTiger<br>core and my own fork, so I intend to try and get as many of my changes<br>put into the V5x core as possible - but the bottom line is that there<br>will be things that my management want in our CRM that nobody else in<br>the world will want, and that's fine.<br><br>> Stand behind the OSS project in all<br>> it's glory and be at the mercy of a project with no direction or<br>leadership, or fork and be in charge of their own destiny. <br><br>I literally had no choice. I was directed to make the CRM do certain<br>things (after all, I have the source code) and "it doesn't do that out<br>of the box" was NOT an acceptable answer. Even "that's coming in the<br>next version of the CRM" is increasingly hard to justify, given how long<br>it has taken for 5.0 to solidify.<br><br>Some of the things I have done are really very pretty. Others are<br>horrible, horrible hacks (my version supports localized currencies, with<br>exchange rates, but you don't want to know how....)<br><br>Other changes are less obvious. For example, I was required to modify<br>the Quote engine so that it preserved the order that products were added<br>to a quote and printed them out accordingly - totally cosmetic, but our<br>sales guys had a valid need for that to happen, so I did it.<br><br> <br>> It really comes down to options 2 and 3, and who wants to double all<br>> their work when you know damn well that 4.x is going to be abandoned<br>now<br>> that 5.x shows the promise it does. And I mean that with absolutely<br>no<br>> disrespect for the people working hard on maintaining 4.x for the<br>> community. <br><br>Bingo. As far as I am concerned, 4.x is a dead tree being maintained<br>only as long as necessary to get 5.x established, after which it will be<br>dropped.<br><br>But the habits that NEED to be carried into 5.x MUST be established NOW.<br><br>Comment your code.<br><br>Every IF has an ELSE - even if that ELSE should never ever execute.<br><br>Simple simple simple; but yet they pay enormous dividends later on.<br><br>DG<br><br>_______________________________________________<br>Get started with creating presentations online - <a href="http://zohoshow.com?vt">http://zohoshow.com?vt</a> <br>
</xbody>
</html></blockquote></body></html>