Hi Seb et al, Like I said before, I'd would have opted for CamelCase (without the underscore) earlier in the project. However;
- IMO it is most important to have a standard. Having the standard does not make me wonder if it is serial_hw_data or SerialHwData. So it saves brain-power, useful for the real issue at hand. - It is indeed a matter of taste and (like Seb) I don't see why this would make a significant 'stopper'-factor. Enlighten me if I miss something. - Mixed casing for the same symbol is IMO a bad thing, since it makes code look messy. So in any case, we need to enforce case sensivity within jallib. - I would have opted for CamelCase. Not Camel_Case, which is IMO the worst of both worlds. - Changing to CamelCase would break all existing user code. Even I, beeing pro-CamelCase, think this price is too high for the benefits. Bottom line: my vote is on retaining the current standard: although not CamelCase, it is clear (requires less brain-power than mixed cases), is widely adopted and we have tools to support it. Joep 2012/1/29 Sebastien Lelong <[email protected]>: > 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 >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/jallib?hl=en. >> > > > > -- > Sébastien Lelong > > > -- > 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. -- 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.
