## Intro
Code Beauty / Project Beauty
by
Christoph Lohmann <
[email protected]>
## Repetition: Bitreich Principles (0/6)
KISP – Keep It Simple Perfect
* Make one tool for one task.
* Keep the size of the tool small enough so one person can grasp it.
* Decide when the tool is done, then maintain it.
* If you have some other idea, create a new project.
* Base the tool on principles.
* This will allow the tool to be used in ways you cannot
imagine now.
## Repetition: Bitreich Principles (1/6)
Commandline Interfaces
* This allows easy integration into scripts and any modern workflow.
* Pure GUI restricts your application to only certain users.
* You want expert users to get new ideas. Experts use the commandline.
## Repetition: Bitreich Principles (2/6)
When Possible Use GPLv3
* This is not a need.
* Use BSD or MIT if you like.
* In the long run (A)GPLv3 allows getting changes from commercial criminals
who do not give back.
* This makes you sleep better.
* You do not need to run around enraged and destroy your Linux
distribution. (See Void Linux.)
## Repetition: Bitreich Principles (3/6)
Users Are Programmers
* Always think of programmers seeing your code and wanting to modify it.
* See programmers who would like to use some flag in the API.
* See the person who would like to help you with changing a typo.
* If you use some cumbersome documentation format, noone will
easily learn it.
* Programmers have a certain lifetime to expend too.
* Do not force down their throat your new overcomplex hipster
language.
## Repetition: Bitreich Principles (4/6)
Bugreports Are Patches
* If you write a tool for programmers, expect them to be programmers.
* If you really write for end users, then the error reporting should not
be a bug report, something simpler.
* The bug report culture is not easy to grasp and different to
the normal world.
* Bug reports are for mediocre programmers.
* Force people to become better programmers, let them send patches.
## Repetition: Bitreich Principles (5/6)
Straightforward Documentation
* Make one entry point to the documentation and keep to it.
* README
* Manpage
* Source Code
* Do not use some nice looking but not easily accessible documentation.
* A web browser is required to view the doc?
* javadoc?
* GNU info pages anyone?
## Repetition: Bitreich Principles (6/6)
Freedom of Language
* Use whatever you like, but keep to the other principles.
* Many languages force you into ugly behaviour.
* Keep to the Code Beauty.
* This is what this talk is about.
* This list is not complete.
## Beauty Disclaimer
* This is my view on beauty.
* Beauty is in the eye of the beholder.
* Everyone has a different view on beauty.
* There is never one definition of beauty.
## How I Evaluate Project Beauty (0/4)
1. Download
% git clone git://something
% hurl
gopher://something/some.tar.gz
* NOT
% curl -sLy --with-root --with-kubernetes startup.io/install.sh | sh
* NOT
> Click on hidden button on website.
> Agree to NDA.
> Wait for Redirect.
> ...
## How I Evaluate Project Beauty (1/4)
2. Extraction
% tar -xzf some.tar.gz
* NOT
% ./install.sh
* NOT
> Manually install requirements for huge stack of software.
## How I Evaluate Project Beauty (2/4)
3. Compilation
% make
# See options by reading config.mk.
* MAYBE
% ./configure --prefix=/usr --some-option
% make
* NOT
% ninja-my-ass
Command not found: ninja-my-ass
% emerge ninja-my-ass
Building package ninja-my-ass required 102 dependencies and a Ruby
upgrade. Please upgrade the whole system.
## How I Evaluate Project Beauty (3/4)
4. Dependencies
% make
# Done
* NOT
% ./configure --prefix=7usr --some-option
Specific version of mesa is required to build this. Newer versions are
not supported.
* NOT
% make
Perl is required to build a small example script. Please install perl.
## How I Evaluate Project Beauty (4/4)
5. Running It
% ./app -h
% ./app -f something -c something
* NOT
% kubectl apply -f cat-with-highlight.yaml
% kubectl get pods
% catctl attach -s localhost run cat
## How I Evaluate Code Beauty (0/2)
* Different languages have different ideoms.
* Things that make me not use a language:
* »::«
* »<someclass,<someclass>>
* »Type<&Something>«
* Simple language syntax can be uglified too.
* See python and newer syntax.
* Make it easy to find modules/includes.
* Even C is bad here sometimes.
## How I Evaluate Code Beauty (1/2)
* Did the developer think of other developers reading it?
* Please use English everywhere.
* Do not use paths to modules.
* The java way of sub directory of sub directory is wasting
lifetime.
* Do not depend on some GUI with auto generation.
* If something needs auto generation it should die and never
be used again.
* Always ask yourself: Can I sleep good at night for the code I
produced?
## How I Evaluate Code Beauty (2/2)
* Do not depend on ugly libraries, just because it is cool.
* Think of the many years lifetime wasted to build boost, but
it never boosted anything.
* Think of small devices, which cannot compile in libreoffice to
generate your documentation.
* The big ugly to compile projects make distributions a hell
to maintain.
* If you do not care, you do not care about open source.
* See open sourcing something as a chance.
* Corporated locked-in source is most of the times ugly and
not easy to maintain.
* By open sourcing you change the perspective to think of the
next programmer reading this.
## See The Beauty In Others
* This was my view on thing.
* There are many views.
* The real beauty is, if something is seen as beautiful by others.
* Think of the others when writing code.
* Think of the others when packaging something.
* Think of the others when you add some dependency.
* Think of your future self having to maintain what you have
just done.
## Questions?
Do you have any questions?
## Thanks!
Thank you for listening!
Send any comments to:
Christoph Lohmann <
[email protected]>
