I would like to move to camel case, but a script would need to be written to go through all files to replace variable names removing all "_" and adding capitals to each word in each variable. Buildbot would need to validate camel case. I doubt any of this would happen.
Please stick to one standard. Without all files being the same standard, I'll have to say no to the suggestion. I don't think we need to change spacing to tabs. Matt. On Jan 29, 5:54 am, Sebastien Lelong <[email protected]> wrote: > Hi guys, > > Regarding lower_case, CamelCase, indentation, etc... here's what I can say: > > - AFAIK it was a democratic decision to go with lower_case > - considering a representative group of people, you'll have 50% who likes > lower_case, 50% who likes CamelCase. Same with indentation. > - this is "just" about aesthetic, and not just about aesthetic. In the end > this is about having normalized code, easy to search for instance, as you > know how things are supposed to be displayed. This is not just to bother > people, this is about best practice coding. > - I understand JSG is very strict on this. It reports any violation. I'm > mostly concerned about public variable (not local to proc), proc/func > signature, and filename, not about local variables for instance. Maybe it > could relaxed a little... :) > - jalv2 is case insensitive. read_results is the same as Read_Result. But > not the same as ReadResult. Considering this, how do we deal with existing > code base, if we switch to CamelCase ?! > * migrate all existing base ? It'll break any user code (and few > laggards won't agree to have their authored library changed). And once > we'll be CamelCased, one will report not to contribute since he wants > lower_case only > * mix lower_case and CamelCase ? it'll bring confusion as well, why > "dht11_read_int" and then "dht11ReadFloat" ? Not consistent, you'll always > wonder which to "guess" > * what about Pseuso_Camel_Case ? same for jalv2 compiler, and user > writes as they want. > - is it possible that this is annoying just on few examples ? Some reported > it was weird to write Celsius with a "c", not with a "C". > > These are the bullet points I could put to sum'up what's already been said. > What do you guys think ? > > And... how can lower_case be a real stopper to the guy who wants to > contribute, btw ? That's something I truely don't understand. AFAIC I'm > using both on different projects (but not both on the same), but my mind > might be too flexible :) > > Cheers, > Seb > > 2012/1/26 Rob Hamerling <[email protected]> > > > > > > > > > Hi Sunish, > > > I'm not so concerned about the popularity of Jal/Jallib! > > My 'complaint' was about the lack of reponse on the latest release of > > Jallib. I'm concerned that this may be a reason for people to reduce their > > efforts for Jallib or even leave the Jallib team (including myself). > > > On 01/25/12 07:03 pm, Sunish Issac wrote: > > > Even though I like and use jal a lot, I consider using C when there's a > >> need for fixed/floating point and string processing. > > > In Jallib there is a limited set of functions for fixed point arithmetic > > and string processing. What is missing exactly which would make you (and > > hopefully others!) to stick to Jal? > > > There should be compelling projects and samples. > > > These can only be provided by experienced users. Maybe these are the > > people who need Jallib the least for personal use and have not so much > > interst to contribute... > > > Providing blink an led for every supported PIC of jallib in the > > > > samples folder just add to noise. > > > I agree that 400 blink samples in a library of 1000 'real' samples may be > > too many. We could consider splitting the sample library in 'basic' and > > 'advanced' or even more (but not too many!) subdirs. > > > IMHO among the many reasons, one reason of less contributions > >> to projects of jallib is the restriction of not allowing > > > > CamelCase in variable names. > > > I am a supporter of CamelCase, but I don't remember the reason for the > > decision, probably a democratic majority. If this is really a reason not > > to contribute then we should reconsider this. > > > Thanks for your arguments. > > > Regards, Rob. > > > -- > > R. Hamerling, Netherlands ---http://www.robh.nl > > > -- > > You received this message because you are subscribed to the Google Groups > > "jallib" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to jallib+unsubscribe@** > > googlegroups.com <jallib%[email protected]>. > > For more options, visit this group athttp://groups.google.com/** > > group/jallib?hl=en <http://groups.google.com/group/jallib?hl=en>. > > -- > Sébastien Lelong- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
