From: Phil D. <ph...@lo...> - 2014-09-11 05:59:43
|
> I bet 90% of developers find easier to understand a script of 300 lines instead of one of 600 Well the thing is we are really not talking about reducing the amount of code to understand - we are talking about dotting it around in a multitude of new files. You still need to understand the 600 lines - but now you have to open 30 files to identify where it is .... actually MUCH more difficult IMHO - maybe we must agree to differ. We would have a bunch of functions that you have no idea in which file to even find them - grep is the best bet before you can even find the code. Alternatively we have a load of includes which at least we know where the code is. Yes we have the advantage that we can reuse these functions and includes and we can write the code once - but in many cases the code is actually slightly different so we end up with a multitude of ifs to accommodate the different uses for the similar code. Where there are serious reuse possibilities then please do discuss your proposal with me first. See http://www.weberp.org/Development.html *1.*Join the developers me ailing list. http://lists.sourceforge.net/lists/listinfo/web-erp-developers Inform the list of your proposed developments and discuss the approach to be used. There are some knowledgeable people on the list and they can contribute ideas if you let them. Alternatively, there is a section on the webERP forum for posting development specifications for what you propose to do. Of course, if I have any concerns about a proposal then I will chime in. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 11/09/14 15:03, Pak Ricard wrote: > Hi all: > > Agree that we need to focus in new stuff, but also think that we > mostly create new stuff based on current scripts, so the better > (readable and short) they are, the better and faster we can create > new stuff and the test will be easily done. > As Phil pointed out, I learned PHP with webERP (I am computer > engineer, so I had some background), but I bet 90% of developers find > easier to understand a script of 300 lines instead of one of 600 > > Well, we should move ahead, but the initial reason of this thread is > still there: > Should Rafael's work on TableRows be accepted or not? > When we find something like the CalculateDemand (i just had to create > another script using demand), should we create the function and "clean > up" some scripts so they use the abstraction? or will the job be > rejected? > > I think we the developers should know, and avoid the frustrating part > of spending some time in a commit to see it reverted and not useful. > > > > Regards, > Ricard > > 2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm... > <mailto:hex...@gm...>>: > > *Dear all,* > > I agree with Phil that we should pay more attention to > those old > codes' (or called redundant?). The abstraction to avoid have at > least some > merit that: > 1. If there is a bug in the code, it's very clear. > 2. I believe in most of time, it's fast. > 3. If we change these tested stable codes, it becomes > green code. > It introduce new risk to our users. > 4. And most of the time, it sacrifice the readability. > Because we > have to understand a new definition which seems intuitive to the > author but > others have to study it. > > I think most of the time, I don't like the code style of > webERP > because I cannot code fast. Its a hand-make style and not > economic. But the > style make those codes reliable and robust and fast. And it's very > easy to > modify what you need to do is just to search those strings you need. > > So lets focus on adding new features instead of those > existed > codes or the coding convention, IMHO. > > Best regards! > > Exson > > > > > > > > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |