jm + guidelines   6

Go best practices, six years in
from Peter Bourgon. Looks like a good list of what to do and what to avoid
go  golang  best-practices  coding  guidelines 
may 2016 by jm
The problems with forcing regular password expiry

The new password may have been used elsewhere, and attackers can exploit this too. The new password is also more likely to be written down, which represents another  vulnerability. New passwords are also more likely to be forgotten, and this carries the productivity costs of users being locked out of their accounts, and service desks having to reset passwords.
It’s one of those counter-intuitive security scenarios; the more often users are forced to change passwords, the greater the overall vulnerability to attack. What appeared to be a perfectly sensible, long-established piece of advice doesn’t, it turns out, stand up to a rigorous, whole-system analysis. CESG now recommend organisations do not force regular password expiry.
cesg  recommendations  guidelines  security  passwords  expiry  uk  gchq 
april 2016 by jm
A Guide to Naming Variables
good rules of thumb for variable naming, from ex-coworker Jacob Gabrielson
guidelines  rules  naming  variables  coding  style 
april 2016 by jm
Google Java Style
A good set of basic, controversy-free guidelines for clean java code style
style  java  google  coding  guidelines  formatting  coding-standards 
february 2015 by jm
JPL Institutional Coding Standard for the Java Programming Language
From JPL's Laboratory for Reliable Software (LaRS). Great reference; there's some really useful recommendations here, and good explanations of familiar ones like "prefer composition over inheritance". Many are supported by FindBugs, too.

Here's the full list:

compile with checks turned on;
apply static analysis;
document public elements;
write unit tests;
use the standard naming conventions;
do not override field or class names;
make imports explicit;
do not have cyclic package and class dependencies;
obey the contract for equals();
define both equals() and hashCode();
define equals when adding fields;
define equals with parameter type Object;
do not use finalizers;
do not implement the Cloneable interface;
do not call nonfinal methods in constructors;
select composition over inheritance;
make fields private;
do not use static mutable fields;
declare immutable fields final;
initialize fields before use;
use assertions;
use annotations;
restrict method overloading;
do not assign to parameters;
do not return null arrays or collections;
do not call System.exit;
have one concept per line;
use braces in control structures;
do not have empty blocks;
use breaks in switch statements;
end switch statements with default;
terminate if-else-if with else;
restrict side effects in expressions;
use named constants for non-trivial literals;
make operator precedence explicit;
do not use reference equality;
use only short-circuit logic operators;
do not use octal values;
do not use floating point equality;
use one result type in conditional expressions;
do not use string concatenation operator in loops;
do not drop exceptions;
do not abruptly exit a finally block;
use generics;
use interfaces as types when available;
use primitive types;
do not remove literals from collections;
restrict numeric conversions;
program against data races;
program against deadlocks;
do not rely on the scheduler for synchronization;
wait and notify safely;
reduce code complexity
nasa  java  reference  guidelines  coding-standards  jpl  reliability  software  coding  oo  concurrency  findbugs  bugs 
march 2013 by jm
Notes on Distributed Systems for Young Bloods
'Below is a list of some lessons I’ve learned as a distributed systems engineer that are worth being told to a new engineer. Some are subtle, and some are surprising, but none are controversial. This list is for the new distributed systems engineer to guide their thinking about the field they are taking on. It’s not comprehensive, but it’s a good beginning.' This is a pretty nice list, a little over-stated, but that's the format. I particularly like the following: 'Exploit data-locality'; 'Learn to estimate your capacity'; 'Metrics are the only way to get your job done'; 'Use percentiles, not averages'; 'Extract services'.
systems  distributed  distcomp  cap  metrics  coding  guidelines  architecture  backpressure  design  twitter 
january 2013 by jm

Copy this bookmark: