Mr. Conway suggets using the reverse builtin when appropriate. This includes with sort, and for counting backwards. Read the rest of this entry »
PBP: 100 Reversing Lists
June 11th, 2015PBP: 099 Sorting
June 8th, 2015The Best Practices have things to say about many of Perl’s built-in functions. Besides the general advice “use them” – which I agree with – it has some specific suggestions. First up: Sorting Read the rest of this entry »
At YAPC::NA
June 7th, 2015Not only did I make all the arrangements in time, I made my flight and have found the hotel. I am checked in and sitting in a room full of geeks having a hackathon.
It’s a room full of pretty serious computer users. I am not the only one in the room who has configured UUCP, for example.
Fun so far!
PBP: 098 Proofreading
June 1st, 2015It is a Best Practice to check the spelling, syntax, and sanity of your documentation. I agree with this, strongly. Read the rest of this entry »
PBP: 097 Discursive Documentation
May 7th, 2015The PBP suggests a way to put longer blocks of documentation in code, by using the =for or =begin/=end notation in POD. By labeling these with a “formatter” that does not exist, they’ll never be output and are merely ignored by the compiler and for the author’s use. Read the rest of this entry »
PBP: 096 Indicative Documentation
May 4th, 2015The Best Practices suggests that a need for a lot of comments explaining things might indicate that the section of code is confusing and could be written more clearly. Rather than writing words to try and explain it, can the code itself be clearer? Read the rest of this entry »
PBP: 095 Defensive Documentation
April 9th, 2015This practice is simple, and probably covers a lot of the places I appear to have been waffling between one view and another. The book says to comment anything that puzzled or tricked you. Pretty simple? The questionable part is that everyone will find different issues tricky. Read the rest of this entry »
PBP: 094 Elucidating Documentation
April 6th, 2015The Best Practice discussed here is to use short comments at the end of the line to provide extra detail and make possibly obscure code a little clearer. I think this can be very useful, but I’m not sure it plays well with a 78 character margin as suggested elsewhere, especially if the function involved is complex and you’re more than a couple of tab stops from the margin. Read the rest of this entry »
PBP: 093 Algorithmic Documentation
March 26th, 2015The Best Practices suggest using a full-line comment before a paragraph of code to explain the algorithm. This is, in my experience, good advice, and what comments should be used for. Read the rest of this entry »
PBP: 092 Comments
March 23rd, 2015The Best Practices suggest creating a template for block comments that are suitable for your team. On the whole the reasons given in the book are good ones and it sounds like a great idea, but I find it harder to implement in practice. Read the rest of this entry »