Let old lib code be as it is if that's a problem. I too would just want variable names as camel case. That's all.
Sunish On Mon, Jan 30, 2012 at 10:04 AM, mattschinkel <[email protected]>wrote: > 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. > > -- 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.
