State of Blockchian Buidl: Do’s and Don’ts
Introduction
In recent years, the blockchian technology has flourished three folds leading to many novice programmers to start coding. In 2014, IDC calculated the number of developers to be approximately 18.5 million that rose to 21 million according to Evans Data Corporation in 2017. Recent studies show that there were almost 23 million developers in 2018. Statistics are expected to increase more by 2023 to 27.7 million approximately. Blockchain industry is the new craze as it offers a promising future to the developers. The statistics in Blockchain industry are astonishing, only in REST APIv3, the total number of developers has increased. Let us take an example of an author “octocat”, his statistics are mentioned in the code below:
Variables: total — The Total number of commits authored by the contributor. Weekly Hash (weeks array): w — Start of the week, given as Unix Timestamp a — Number of additions d — Number of deletions c — Number of commits “Total”:135, “weeks”:[ { “w”: “1367712000”, “a”: 6898, “d”: 77, “c”: 10 }
The number of deletions is around 77, which is quite high considering it has caused significant time wastage which could be considerably reduced if proper code practices would have been followed.
Comparing Cardano vs Ethereum vs EOS vs Binance Chain Repositories
Cardano, Ethereum and EOS are one of the most notable blockchain projects and cryptocurrencies. Below, this article compares the repositories of all three of the cryptocurrencies by discussing the number of commits, the number of lines added and the number of lines deleted to evaluate the time wastage that occurs due to the bad code practices, new developers are used to.
Cardano:
Fig. 1: Cardano Repository
Fig. 1 shows the profiles of developers that commit to Cardano in the duration Sep 25, 2016 to Mar 8, 2019. Let us consider the top developer, the number of commits done is 2200. The number of lines added is around 167,608 and the number of lines deleted is 162,618.
EOS:
Fig. 2: EOS Repository
Figure 2 shows the profiles of developers that commit to EOS in the duration Apr 2, 2017 to Mar 8, 2019. Let us consider the top developer, the number of commits done is 77. The number of lines added is around 2,886,948 and the number of lines deleted is 2,887,142.
Ethereum:
Fig. 3 Ethereum Repository
The picture above shows the profiles of developers that commit to Ethereum in the duration Dec 22, 2013 to Mar 8, 2019. Let us consider the top developer, the number of commits done is 2,620. The number of lines added is around 5,643,144 and the number of lines deleted is 2,645,582.
Binance:
Fig.4 Binance Repository
Binance is a new candidate in infrastructure development however it is a very well renowned name for buidl. For a newbie, the statistics aren’t bad. Fig.4 shows the profiles of developers that commit to Binance in the duration Oct 21, 2018 to March 8, 2019. Let us consider the top developer, the number of commits done is 22. The number of lines added is around 13,298 and the number of lines deleted is 10,470.
Most popular languages in blockchain development are Javascript and Golang. As they are comparatively new languages, developers are most focused on getting things done than ensuring quality. Comparing all of four blockchains’ development, we could see the number of lines deleted in Cardano and Eos from even their top developers are very high and resources wastage is significant in both of these projects. Ethereum, on the other hand, has less number of lines deleted showing better code practices by its top developer. Binance’s code, despite being new, has shown much improvement than any other blockchain in its initial stage. All of these statistics could be improved by practicing good coding habits even when changes are inevitable.
Bad vs Good Coding Practices
All of the problems discussed above could be avoided by using good code practices. But before that, one should discuss what kind of code stinks. “Bad code” refers to the code which is written without putting any thought about the output and how it could affect the software in the longer run. Good code, on the other hand, is modular and modifiable.
Typos in your Code vs Correct Naming Conventions:
This problem has nothing to do with your programming skills but it causes a lot of bad taste when someone is going through your code for modification because variables’ name should represent the task carried out by it. For example:
Int sum=8;
Int sm=8;
One could easily see the meaning the variable “sum” is reflecting as compared to the variable “sm”. This could save a lot of time for a new developer to make modifications to the existing codes.
Non-Indented vs Indented code:
Bad code is not structured and looks like a mess. The distinction between two blocks of code should be distinct, so an outsider could understand the logic by looking at it. A well-formatted code becomes evident and straight forward. For example:
int main() { return 0; } Vs Int main(){
Return 0;}
You could understand the above mentioned snippet in one go as compared to the second snippet.
Modular code vs Non-modular code:
Always divide the tasks between different functions, meaning write functions that perform only one task and one task only. This keeps code maintained in addition to being short and specific. On the other hand, long functions might call other functions, thus following different paths which makes them hard to test.
Function Books{ //this function adds and deletes books from the libraries } Vs Function addbooks{ //this function adds books into the online library } Function deletebooks{ //this function delete books into the online library
}
Hard-Coding vs Dynamic values:
It seems convenient to hard code certain parameters the first time one is dealing with them. It is a very wrong practice especially for passwords or other sensitive information. If the details get to a wrong hand, it could propagate so fast that it couldn’t be controlled leading to the demise of the whole system. For example:
String password=”Henhen123” Console.WriteLine(“Password :”);
string password = Console.ReadLine();
Optimization vs Well-Structured Code:
Optimization is always a good idea but not at the expense of resources that one could use to make the code more structured and maintainable. Most of the programmers waste their time optimizing the non-critical parts of the programs thus negatively impacting the maintenance process. Function wellstructured {code} { if(i<=10){ //some code here } Else { //some code here }
}
Architecture & Complete Software Requirements vs Architecture-less coding & incomplete software requirements:
The outcome of starting coding without actually thinking about architecture is always negative. One cannot achieve his goals without a plan. Before writing code, sort out your relationship between the libraries and tools, how they will work in harmony, what modules they will be needed, what structures they will have, and how all of them will be tested.
Factors To Ensure Quality in Code
To keep the perfect balance between quality and quick delivery, good code practices should be exercised to keep the code manageable and maintained. Whilst coding, these are a few practices that should be kept in mind:
Security:-
In the software development process, security ensures confidentiality, integrity and availability. Security vulnerabilities in the applications are the result of bad coding practices that happens either intentionally or carelessly. Validating users’ input is a good way to ensure security but there are some loopholes that cannot be avoided. In that case, try and catch block could be used to change the flow of a program.
The secure applications ave following core activities: conceptual definition, well defined functional requirements, test review and maintenance.
Elegance:-
More often than not, developers are keen to solve the problem in hand by any way possible. This might lead them to a much complicated solution thus reducing the software quality on different parameters Elegance in code could be defined in two ways: One, elegant code should be able to define all of the modules in one word, making it more balanced and concise. Secondly, elegant code refers to the most obvious solution of a problem after careful analysis consequently speeding it up. Furthermore, this makes it easier to understand even for the novice programmer so he could continue development without spending hours.
The code should be crisp and concise. You should be able to explain any module in one sentence, and things should be in alphabetical order, if possible. To test if the code is elegant code or not, check if the solution that it provides couldn’t get simpler. Research shows that well written code stays around 10 years, so a little more effort in the analysis could save resources for an extended period of time.
Ease of code management:-
As maintainability is inversely proportional to the complex code, one should always try to make his/her code more manageable. Changes are inevitable so it is very essential to make changes that could be easily integrated.
Modularity i.e. dividing the program into multiple classes and giving a specific meaning to those classes is very important as it makes the code more structured thus making it more manageable.
Agility:-
Agile development needs teams to focus on iterations- choosing what they can do based on their previous experiences and capabilities. Customer oriented approach must be followed in order to ensure agility. It requires constant communication between the team and the customers. Agile development and management also need requirement prioritization to determine which product feature should be included in which phase. Some core agile development practices are as follows: -Test-driven development -Define milestones -Clear system architecture -Simple and shared codebase -Single coding standard -Documentation of all processes -Simple design -Peer code review
-Continuous integration
Reduce Redundancy: One should avoid redundant code completely as it over complicates the code in addition to time wastage that occurs due to ensuring the same task over and over again. DRY rule should be complied i.e. Don’t Repeat Yourself.
Less redundant code would not require anyone to change any logically unrelated elements as everything related to one specific task would be under umbrella only.
Low Coupling: It is always a good idea to keep minimum dependencies i.e. low coupling within your code. If one class is dependent on more than two classes for data and resources, it might face conflict.
To check dependencies within a code, use NDEPEND.
Expressiveness: Expressiveness ensures meaningful names for all the components within a code. One should follow these rules to ensure expressiveness in code These Names should express why a certain component is made and what will be its purpose.
Names should have a distinguishing characteristic. This makes code more understandable without needing to take help from extensive documents.
Ensure Strong Abstraction: Abstraction is the extent to which the implementation details are hidden. While doing something, it usually doesn’t matter how it gets done. The same goes for softwares. It is necessary as: The more one needs to know about how something is occurring, the more effort it needs. Things get more complicated once one tries to make changes to use them elsewhere.
Generally, the software modules should be able to fully utilize the module by knowing how the interface works.
All development teams have different capabilities and different strengths. There is no defined way or set rules for any team to develop perfect products. Still, there are some major factors that every great development team follows, some of which are explained above.
Key Words: Blockchain, Code, Best Practices, Buidl, Developers
References:
https://github.com/EOSIO/eos/graphs/commit-activity
https://developer.github.com/v3/repos/statistics/#get-the-last-year-of-commit-activity-data
https://github.com/ethereum/go-ethereum/graphs/commit-activity
https://github.com/binance-exchange/go-binance/graphs/commit-activity
https://www.quora.com/What-are-the-signifying-difference-between-good-code-and-bad-code