[ale] Coding Style

DJ-Pfulio DJPfulio at jdpfu.com
Mon Oct 15 16:53:50 EDT 2018


If you do team programming, having a coding standards to follow that the
entire team agrees to follow is helpful. The hard part is getting
everyone to agree, but let the best reasons determine the resulting
coding standards. After a month, everyone basically prefers anything
they weren't doing already.

Plus, having someone else review your code is great for spotting dumb
mistakes and passing on knowledge to less experienced members of the
team.  Whenever a problem is found, at least 2 people missed it, so
there's company for the embarrassment.  That's always a good thing for
better code.

IMHO.


On 10/15/2018 01:37 PM, Ed Cashin via Ale wrote:
> A good technique is to find out what linters are the most popular for
> the programming language you're interested in, figure out which one
> you can work with, and defer to its judgement.  Sometimes the linters
> even have documentation for the rationales behind their criteria,
> which can help soothe the pain of conforming to arbitrary-seeming
> rules.
> 
> I was about to say I don't know of a good Bourne shell linter, but
> shellcheck looks pretty good.  I always have to suggest double quoting
> to the student workers I'm working with.
> 
> https://www.shellcheck.net/
> 
> If there's an issue I feel strongly about, but no linter supports
> checks for the issue, then I try to get self-critical and to consider
> the possibility that perhaps I might be too picky.
> 
> 
> On Mon, Oct 15, 2018 at 1:01 PM Scott Plante via Ale <ale at ale.org> wrote:
>>
>> Back in the early 80s when I was first learning Bourne shell scripting, I was taught to use lower case for script variables. CAPS was strictly for environment variables and that was so they wouldn't conflict with local script variables. I do see a lot of scripts that use caps for all variables, so it doesn't seem to be a widely followed norm but it does make sense to me.
>>
>> Separately, some languages have clear norms for this stuff. Almost everyone in Java land uses camel case with variables, methods and class attributes starting lower case, Classes starting upper case, and constants (public static final) being ALL_CAPS snake case.  Indention and curly brace location is not quite as standardized from what I've seen.
>>
>> Scott Plante
>> ________________________________
>> From: "DJ-Pfulio via Ale" <ale at ale.org>
>> To: "Charles Shapiro via Ale" <ale at ale.org>
>> Sent: Friday, October 12, 2018 11:26:30 AM
>> Subject: [ale] Coding Style
>>
>> OOP - CamelCase.  BeginningCaps for methods, classes, camelCase for
>> classData.
>>
>> All others - snake_case.
>>
>> I use type hints in variable names.
>>
>> Shell scripting, ALL_CAPS. 


More information about the Ale mailing list