g-marcin-journal

Comments is a part of code that is not executed during runtime. It should be short, concise and necessary. Comment shall be deemed necessary whenever there is a gap between the story that may be described by code only and actual story. It should be cherry on top that adds value by giving more insight to the logic than the naming, formating and the structure. The overriding rule regarding comments should be - keep your code understendable to yourself and future maintainers(possibly you). Do not attach comments to poorly named variables, functions and modules. Try to include as much context as possible within naming and structure. There is a common practice to set comments ide colouring to same as bacground but it is possible to overlook some valuable comment in this case. i stole the title from the book(original author Cal Evans) regards gmarcin

Another subject from the set of 97 things that every programer should know is simplicity. The most important thing designing software is to provide client with the functionality tailored to their real needs. Managers dont care about tools applied to obtain requested outcome as long as it gets the job done quickly and satisfy the requieements. On the other hand developers mostly need challenge and constant growth. As a consequence nowadays applications tend to be over-engineered and stuffed with additional libraries, frameworks with tons of configuration. Today ive also watched a youtube video of primagean. It was a comment on article titled "Radical simplicity". It is a reason why id written previous paragraph. The article was about technical overhead that is tend to be introduced within the aplications recently. The one good thought was that nowadays applications are able to do more stuff. The main thought was to use the bare minimum and be careful about introducing new d

Recently ive found good book about programming heuristics. It is a set of short articles giving some advice about how to approach problems connected with design and maintenance of software. The title is "97 things every programmer should known". Each chapter is written by experienced developers willing to share their observations with others. The articles are not specific but gives an overview of the problem and highlights things to pay special attention to. One of the chapters says about refactoring. Firstly it is good to take a step back, define a scope of work to be done and analyse its contents as it is. It is easy to juggle the ideas how great solutions we may introduce instead of existing messy, imperfect code. We all know we are good programmers capable of good design and bold ideas. But in this case i recommend stop thinking about what could be and try to emphatise whith the people who were involved in the process of development of code that we intent to refactor.