## Intro

Code Beauty / Project Beauty

by

Christoph Lohmann <20h@r-36.net>

## 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 <20h@r-36.net>