For programmers: tips for functional programming

When we are talking about functional programming, we are talking about speed, efficiency and cross-platform support. Functional code is very close to machine language. It may use intrinsics of the processor, GPU code, SSE/Neon optimization, and lots of pointers. I love functional programming for its purity and no-nonsense approach. Functional programming may be dangerous and spaghetti code in the wrong hands, but in the right hands it can do wonders. Here we try to discuss some aspects that will help you write better functional code using superlearning skillset.

Use code highlighter and more

Always use code highlighter. You can train synaesthesia instead, but code highlighting is good enough.
Do add comments and try to make each function visually different. If you have #defines, use special comment for each case you are handling.
This will allow you to have the whole function’s visual representation on the screen as one visual marker.
It is best if functions are large enough to use between 1/3 and 2/3 of the computer screen.

Meaningful names

Encode your mindmap into function names. You may not have proper classes, but you can totally control the function names.
Try to structure the names in a way that mirrors the code structure in your mindmaps.
Use also meaningful names for the variables, especially if you are going to use void pointers and casting: you need to be able to follow the logic.
If you have a pointer to pointer to integer, do write “ppn” before the variable name.
Try to keep standard interfaces if you can.
As I learnt from FFMPEG code, it is better to cast a void pointer into a structure then have different interfaces each time you execute an operation.

Reasonable file size

Each file in C is like a section in book. It is reasonable to keep a mindmap per file and a mindmap for all files.
If you have too many files or too many functions in a file, your mindmaps become too complex.
For me the perfect file size is between 300 and 1000 lines, this way I can generate good mindmaps and see a file in several pageup/pagedown moves.

Visualize everything

You do not need a UML diagram to visualize the functional flow in your head.
Try to visualize each function call and its meaning. Use visual markers.
Use logging or printf or save files or display other temporary outputs for easier visualization.
If you compare your visualization with actual results, your visualization skills get stronger.

Be consistent

Consistency reduces pressure on your coding, memory and reading.
Try to be consistent in the way you use functions, like having initialize, execute, terminate interfaces.
Keep all your pointers in initialize and terminate to reduce possible leakage.
Add error handling where you can.
Use singletons and design patterns to reduce the memory usage.

Keep it simple

Please avoid complexity, even if it means several extra lines.
Add parenthesis in mathematical and logical computations to avoid possible issues.
Remove all warnings by using explicit variable casting and other simple remedies.
Do not use templates, macros and vectors if you can avoid them.
It may be easier to write an inline function twice than to debug it in template or macro form.

Skim the code, do not read it

By putting comments in key locations and keeping reasonable function names you can skim the code instead of reading it.
This way your code reading will be blazing fast, and you will be able to integrate with others easily.

As you can see the tips are very simple, and apply not only to the functional code.
Simple, meaningful and visually pleasing code – we already know this is desirable, now we just have more reasons to generate such a code.