1.9 KiB
| layout | title |
|---|---|
| site | Join the fun |
###Join the fun
I am very open for people to join.
I just want to mention that this is my hobby, something i do in my spare time, for fun. I don't get any money and in fact, running 2 companies, have to carve the time to do this.
As such i want it to stay fun. So i am looking for friendly, constructive, positive contact.
Please read the pages and the code and find something that interests you, possibly from the todo list. Then talk to me what you are planning. Issues can be good to capture topic conversations, as there is no list.
Then fork and work on a branch before sending pull request.
I wrote some ideas in the about page, but here some more code related guidelines
-
Walk the straight line Or "No futureproof" means not to design before you code. Not to anticipate, only to do the job that needs doing. Better design should be extracted from working code.
-
tdd extreme Having suffered from broken software (small feature add breaks whole software) so many times, the new tdd wind is not just nice, it is essential. Software size is measured in tests passed, not lines written. Any new feature is only accepted with enough tests, bugs fixed after a failed test is written.
-
Use names rightly or the principle of least surprise. Programming is so much naming, so if done right will lead to a natural understanding, even of code not read. Good names are Formatter or compile, but unfortunately not everything we have learnt is named well, like Array (should be ordered list), Hash (names implementation not function) or string (should be word, or bytebuffer).
-
No sahara There has been much misunderstood talk about drying things up. Dry is good, but was never meant for code, but for information (configuration). Trying to dry code leads to overly small functions, calling chains that are difficult to understand and serve only a misundertood slogan.