good chemistry is complicated,
and a little bit messy -LW
How has your coding style changed over the years?by stevieb (Canon)
|on Aug 07, 2022 at 01:42 UTC||Need Help??|
Since I started coding C and C++ in 2000, and Perl very shortly afterwards, my style hasn't fundamentally changed. If anything, I've simply become more pedantic about certain things. I'm bored so I thought I'd put a list together off the top of my head. What's your list look like?
- Four space tabs!
- I like no space between function parens:
- I'm very much a K&R style person who likes 'else' type statements on their own line:
- When dereferencing a list, I always use whitespace:
- I always use the deref indicator where it is needed:
- In my personal Perl code (60+ CPAN distributions), I always put the POD at the bottom of the file after all code (at $work, it's inline):
- I *ALWAYS* write unit tests before or at least during writing each function/method. I use the test scripts as test runs to prototype the code I'm writing instead of having a separate script. The test scripts are inherently part of the test suite. I also *ALWAYS* review my unit test suite for each piece of functionality and update it if necessary if patching/updating subs days, weeks or years later.
- I (almost) *ALWAYS* write POD documentation as I'm writing the code (rarely before, but sometimes I do that too).
- I frequently peruse the documentation of a random publication of my own software (regardless of language), and make fixes or produce relevant updates I may have missed.
- I use the same editor all the time (vi/Vim) when I don't have my IDE handy, intelliJ IDEA (with vim support, of course). (VSCode for some of my work projects).
- I rarely have to use the perl debugger, because I almost always find base issue cause through Data::Dumper statements. If I do use a debugger, it's more often for C code than it is for Perl code.
- One of my favourite topics for new development is writing code to help other developers (including me). Introspection and unit test software is a big thing for me.
- I love PPI, and am fluent enough with it that I rarely need to refer to the documentation when I want to use some of its functionality.
- For my Perl code, I strive with great effort to achieve 95%+ unit test coverage, and that coverage generally covers that 95% 16 ways from Sunday. I often write additional code just so that tests can test code it just cant cover. This includes special constants, env vars etc. Some of my software has complete routines as add-ons just to get a single statement covered that otherwise couldn't have been.
- I use Continuous Integration testing (CI) for almost everything. Mostly Github Actions (formerly Travis CI until they pissed me off tremendously), but some of my code can't run there, so I use my own Test::BrewBuild for such software.
- I used to, but not so much anymore, review CPAN latest releases to try to find bugs to fix, even if its just documentation.
- I am very specific about honouring other artist's copyright information. To further, I regard and honour the license of projects I've taken over from other authors. I'm a published author, poet, lyricist and music producer so the copyright thing in ingrained and imprinted. Appreciating other's art ownership isn't a desire to me, it's a core instinct.
- I am diligent in acknowledging contributors to my software. My Changes files and commits generally have the persons name and/or CVS username embedded.
- I take criticism very well; that said, I *ALWAYS* give credit where it is due, and *NEVER* claim credit for things I did not myself do
- I take bug/issue/feature requests very seriously, and do my utmost to respond in as timely a manner as I humanly can (sometimes I don't, but that's very rare).
- I use a bug tracker for almost everything I find myself; new features, real life bugs, security issues or even POD typos. If I'm perusing a random distribution of my own and I see a typo in the SYNOPSIS, I create a ticket for it.
- I never use shift in an OOP module, I always use my ($self, ...) = @_;
- I *ALWAYS* do parameter validation in each and every function/method.
- I use pure perl OOP; very, very rarely do I ever use any of the helpers. The only time that happens is if I'm requiring a distribution that has that required already.
- My POD format for subs is typically:
- I very sparsely use comments. Almost always my comments within code refer to *why* something is happening. It very rarely (if ever anymore) refer to 'what' is happening. The code says what is happening. Said comments when I make them are generally one to two lines only, and I use them only when I, myself will need to be reminded why in the fsck I did something so bizarre.
I'm sure I can add a hundred other particulars I've formed over the years, but that's a start. How about you?