Posts
-
4 simple rules for better writing method and variables
Programming is an art and programmers are artists. As any artist anyone has a different approach for crafting, besides that there are some common rules that would help you writing better software. In fact is really important to write software not just that “works” but also that is easy to read and unterstand. In fact Brian Kerninghan (C creator) has written:
“Good programming is not learned from generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient, and reliable, by the application of common sense and good programming practices. Careful study and imitation of good programs leads to better writing.”
You may now say that for you writing software easy to read is not that important, but in fact you are wrong.
If you read software hard to understand the next time you read that code to make some changes you will have an hard time and spend more time than intended. Writing unreadable code is even worst if you work in a team: imagine if your team partner need to edit some code you wrote days ago in a “bad way”, how you think he would feel? How many times you to saw some rot code and said: “what the hell is that?” and how you think your life as programmer would be if that won’t happen to you anymore?
In fact writing understandable software is really important and i think that don’t respecting this rule is unprofessional.
So now i think you agree with my opinion, but now comes the hard part: how can you write code easy to understand? The answer is not simple at all, in fact you need a lot of practise and experience to achieve that goal. But the title of this post is: “4 simple rules for writing method and variables”, so now we will focus on simple rules for writing better methods and variables. -
How to effectively use composer artifacts
Hello guys, some days ago i had to setup a private composer repository without using a VCS. After reading the original documentation i encountered some issues. For this reason i decided to make a post on my website that explains better the overall process. The first thing you need to do is to setup a version of your composer package, so open the composer.json file and add the tag: “version: version_number”. After that you need to zip the whole package directory: the zip file should contain only the file of your composer package, excluding the vendor name and the package directories.
For example let’s assume you have a package in “workbench/vendor/package_name” what you have to do is to create a zip file named vendor-package_name-version.zip that contains all the files inside the package_name folder (excluding the folder itself). At this point you have to create a directory in the same folder of your composer.json application file, in this example i call it “artifacts. In that directory you put your package.zip file. Now in your main composer.json you have to add the following lines: -
How to import and export data gracefully with php and laravel
Hello guys, during my career i’ve come across the problem of importing and exporting data from and to different formats many multiple times. For this reason i want to share with you my general approach to solve this problem. The process of importing and exporting data mainly is just a process of data trasforming; for this reason the import and export operations can be seen as the same of data transformation. After realising that i started to think a smart way to solve the problem gracefully. What i decided to do is to separate the process in three parts:
-
SOLID Design principles and Php: Dependency inversion
This is the last article about the SOLID principles series. In this article we talk about the D in SOLID: “Dependency inversion”. This last part may be the harder to understand for you guys. Before saying the principle we need to explain some definitions:
- High level code: the code that is focused on solving a general problem (For example db access)
- Low level code: the code focused on solving a particular problem. Keep this definition as it is for now, the Dependency inversion principle says: Every implementation of high level code should not depend on the implementation of low level code, instead should depend on an interface. Again as you see all the principles gets into the “Program the interface” principle. This principle is based on reducing coupling between the code, allowing easier testing and mantainance of the code itself. Now let’s dig in with an example: Imagine we are handling a subscription form and at one point we need to send an email to the client.
-
SOLID Design principles and Php: Interface Segregation
Ok guys we’re almost done with the SOLID principles series, today we talk about the interface segregation principle. The Interface segregation principle says: “A client should not be forced to implement and interface that doesn’t use”. As we are used let’s explain that with an example. Imagine we are using the repository pattern to save some objects.
subscribe via RSS