…In what I hope will be a long line of posts :P
I think its safe to say that its now officially full-steam
ahead.
-x
Related posts:
Chrome can now save all open tabs to a bookmark, which nicely complements erdinç’s solution. To do this, just right click any tab, and choose “Bookmark all tabs”. It will create a new folder and store all the tabs there, you just need to rename the folder afterwards. I tested this on version 4.0, not sure about older versions.How do I save tabs? - Google Chrome Help
T1: Insufficient Tests - A test suite should test everything that could possibly break. The tests are insufficient so long as there are conditions that have not been explored by the tests.
T2: Use a Coverage Tool - Coverage tools report gaps in your testing strategy
T3: Don’t Skip Trivial Tests - They are easy to write and their documentary value is higher than the cost to produce them
T4: An Ignored Test Is A Question About an Ambiguity - Sometimes we are uncertain about a behavioural detail because the requirements are unclear. We express this questioning as a test which is commented out or marked as [Ignore].
T5: Test Boundary Conditions - Take special care to test boundary conditions. We often get the middle of an algorithm right, but misjudge teh boundaries
T6: Exhaustively Test Near Bugs - Bugs tend to congregate. When a bug is found, it is best to comprehensively write tests to cover the function - bugs don’t hang around alone!
T7: Patterns Of Failure Are Revealing - Sometimes you can diagnose a problem by finding patterns in the way the test cases fail. This is another argument for making the test cases as complete as possible. It will help to lead to an “aha!” moment when analysing test failures.
T8: Test Coverage Patterns Are Revealing - Looking at code that is or is not executed by the passing tests gives clues as to why the failing tests fail.
T9: Tests Should Be Fast - A slow test is a test that won’t get run. When things get tight, the slow tests will be the first to drop. Do everything you can to keep the tests small and fast
Clean Code: Chapter 17
Advice re Procrastinating on finishing projects:Why can I never finish what I start? : AskReddit
You have to get into the same mentality you have when you’re masturbating. You don’t just say “ah, fuck it” and release your solid penis grip. You see it through and rub that shit out so your head is free from the influence of women’s mind tricks.
So every time you need to see something through, imagine you are masturbating and see it through to the end.
2,$s/pick/squash/g
Calling Atheism a religion is like calling bald a hair colour. - Don Hirschberg (via @quackingduck)Twitter / stevenringo: Calling Atheism a religion …
N1: Choose Descriptive Names - Dont be too quick to choose a name. Make sure the name is descriptive. Names are what makes 90% of the code readable.
N2: Choose Names At The Appropriate Level Of Abstraction - Don’t pick names that communicate implementation; choose names that reflect the level of abstraction of the class or function you were working in?
N3: Use Standard Nomenclature When Possible - Follow existing conventions in the code when used. For instance, calling all controllers the {something}Controller keeps names consistent.. Each project has it’s own conventions for naming - these are known as the ubiquitous language of the project.
N4: Unabmiguous Names - Choose names that make the workings of the function or variable unambiguous.
N5: Use Long Names For Long Scopes - The length of the name should be related to the scope. Tiny variables can have short names but wider scoped members should have longer names.
N6: Avoid Encodings - Names should not be encoded with type or scope prefixes. Hungarian Pollution.
N7: Names Should Describe Side Effects - Names should describe everything that a function does, including side-effects. Don’t hide side effects within the name.
Clean Code - Chapter 17
G28: Encapsulate Conditionals - Boolean logic is hard to understand without having to see it in the context of an IF..THEN. Extract the boolean logic into a function which clearly expresses the intention of the conditional from the clause which executes it.
G29: Avoid Negative Conditionals - Negatives are harder to understand than positives. Conditional operations should be expressed as positives where possible.
G30: Functions Should Do One Thing - It is often tempting and easy to create functions that have multiple sections that perform a series of operations. Functions should do one thing and should be split up accordingly.
G31: Hidden Temporal Couplings - Temporal couplings are often necessary, but they should not be hidden. For instance, if one method relies on the execution of another one before it in order to maintain state, there is a temporal coupling between the two (ie: the sequence of calls). The hidden sequence coupling could be broken if a caller doesn’t make the calls in the right order. You can expose temporal couplings like this by making subsequent calls stateless and take in any data they need to work on instead of relying on common state. This makes it clear that there is a coupling between the two methods
G32: Don’t Be Arbitary - If code layout and organisation conventions are followed and maintained throughout the codebase, then there is less chance that people will come along and make arbitary changes against the conventions. If there are arbitary random differences, it empowers people to break conventions.
G33: Encapsulate Boundary Conditions - Boundary conditions are hard to keep track of. Put the processing in them for one place. EG: if the value “Level + 1” is mentioned in a number of places, then encapsulate it in a variable.
G34: Functions Should Desccend Only One Level Of Abstraction - The statements within a finctions should all be written at the same level of abstraction, which should be one level below the operation described by the name of the function. Though it seems simple, humans are just far too good at seamlessly mixing levels of abstraction.
G35: Keep Configurable Data At High Levels - Constants such as defaults or configuration values that are known and expected at a high level of abstraction, should not be buried in a low-level function. They should be exposed to the low-level function by way of a parameter that is passed into it.
G36: Avoid Transitive Navigation - Modules should only know about their immediate collaborators and do not know the navigation map of the whole system. The Law Of Demeter is what prevents getA().getB().getC().Something();. Breaking is is how architectures become rigid - they know too much about other modules and breaking that dependency is difficult.
Clean Code: Chapter 17
Clean Code: Chapter 17
G19: Use Explanatory Variables - Break up calculations into intermediate values that are held in variables with meaningful names, rather than inlining them. More explanatory variables are generally better than fewer
G20: Function Names Should Say What They Do - Function names should clearly express what the operation will do. If you have to look at the documentation to find out what it does then you should work to find a better name. (eg: date.add(5) - does this add 5 days, 5 minutes? Does is it modify the existing date or does it return a new one?)
G21: Understand The Algorithm - Programming is often an exploration. You think you know the right algorithm to solve a problem but you poke and prod until you get it to work. Once it works though, you *must* spend the time to understand exactly *why* it works. Refactor the function so that it becomes obvious why the implementation works.
G22: Make Logical Dependencies Physical - If one module depends on another, then the dependent module should not make assumptions (aka logical dependencies) about the module it depends upon. Rather, it should explicitly ask the module for all information it depends upon.
G23: Prefer Polymorphism to If/Else or Switch/Case - There may be not more than one switch statmeent for a given type of selection. The cases in that switch statement must create a polymorphic object that takes the place of other such switch statements in the rest of the system.
G24: Follow Standard Conventions - Every team should follow a coding standard based on common industry norms. There should not be a need to document this these conventions because the code provides the examples.
G25: Replace Magic Numbers With Named Constants - It is bad to have raw numbers in your code. You should hide them behind well-named constants. THis allows the code to be more expressible and the intent clearer. This also applies to magic strings.
G26: Be Precise - When you make a decision in your code, make sure you make it precisely. Know why you have made it and how you will deal with exceptions. If you decide to call a function that might return a null, make sure you check for null. Ambiguity and imprecision in code is either a result of disagreements or laziness.
G27: Structure Over Convention - Enforce design decision with structure over convention. Naming conventions are good, but they are inferior to structures that force compliance. For example, switch/cases with nicely named enumerations are inferior to base classes with abstract methods. Noone is forced to implement the switch/case statement the same way each time, but the base classes do enforce that concrete classes have all abstract methods implemented.
Clean Code: Chapter 17