Dishant Khanna

Final submission post: Engelsystem

Post author:Dishant Khanna
Post published:August 23, 2016
Post category:FOSSASIA GSoC
Post comments:0 Comments

This summer has been really amazing, I learnt a lot and worked crazy hours it has been a crazy yet amazing ride. I am not going to stop working on open source projects and posting the blog post. In this post, I would like to summarize all the work that I did during this summer. Working with FOSSASIA was an amazing experience for me. I got to learn a lot during this summer. Thanks to such amazing mentors. My project Engelsystem is an online tool for helper and shift planning on major events. It lets the user organize their helper in teams, they share in layers or let them decide when and where they want to help themselves. The Project was provided an A-Grade certificate from CODACY. Here the link to view all my GitHub contributions to the project during this summer, https://github.com/fossasia/engelsystem/commits/master?author=dishantk1807 The list of issues solved and features implemented by me is provided below. Themes Issue: https://github.com/fossasia/engelsystem/issues/4 Creating new themes for Engelsystem. Two themes have been added to the system, Engelsystem color scheme-1 and Engelsystem color scheme-2. Languages for Localisation Issue: https://github.com/fossasia/engelsystem/issues/5 Sub-issue: https://github.com/fossasia/engelsystem/issues/52 [Language support-I] Implement localization in different languages as it will make this system reach many people across the world. There 10+ International languages added to the system. The list of languages can be checked in the issue tracker Added Travis-CI Issue: https://github.com/fossasia/engelsystem/issues/31 Setup the Travis-CI for Engelsystem. Added a stable .travis.yml file to the system Feature Request: User: Registration form Issue: https://github.com/fossasia/engelsystem/issues/10 Sub-issues: https://github.com/fossasia/engelsystem/issues/33 [Marking First Name and Last Name as required] https://github.com/fossasia/engelsystem/issues/35 [Adding more item to the Registration form] Adding more fields to the registration form(First name, Last Name, GitHub, Facbook, Twitter, Organization) Feature Request: Admin: Export database of all Angels Issue: https://github.com/fossasia/engelsystem/issues/12 Sub-issues: https://github.com/fossasia/engelsystem/issues/114 [Use temporary files for exporting the database] https://github.com/fossasia/engelsystem/issues/144 [Improve User export] https://github.com/fossasia/engelsystem/issues/155 [remove password hashes from the export] https://github.com/fossasia/engelsystem/issues/154 [Restore Frab import] Exporting the database of the angels in the .csv format. Feature Request: Admin: Shifts: Batch Deleting of Shifts Issue: https://github.com/fossasia/engelsystem/issues/14 Sub-issues: https://github.com/fossasia/engelsystem/issues/113 [Adding checkboxes and delete button] Implementing batch deleting of Shifts in the shifts page allowing the admin to delete multiple shifts at once. Created checkbox for selecting the shifts to be deleted and a delete button in the Shifts page to delete the selected shifts. Feature Request: User: Registration Form and Shifts [Captcha] Issue: https://github.com/fossasia/engelsystem/issues/18 Sub-issues: https://github.com/fossasia/engelsystem/issues/124 [Captcha in the Registration form] https://github.com/fossasia/engelsystem/issues/128 [Captcha in Shifts page] https://github.com/fossasia/engelsystem/issues/132 [Documentation for captcha] https://github.com/fossasia/engelsystem/issues/142 [Refining captcha code] https://github.com/fossasia/engelsystem/issues/148 [Removing keys and added it via config.php] https://github.com/fossasia/engelsystem/issues/148 [enable and disable re-Captcha] Implementing Google re-Captcha in the Registration form and Shifts pages for enhancing the security DB: Convert char(1) to Booleans Issue: https://github.com/fossasia/engelsystem/issues/21 This issue was listed in the engelsystem/engelsystem issue tracker. Bug: Disallow self-signup of shifts Issue: https://github.com/fossasia/engelsystem/issues/22 Sub-issues: https://github.com/fossasia/engelsystem/issues/199 [Create new Groups Page] https://github.com/fossasia/engelsystem/issues/201 [Providing Privileges to the new Groups Created] Disallowing self-signup of restricted shifts when an Engel is approved for certain groups. Created a page to create new…

Auto Upgrade feature in Engelsystem

Post author:Dishant Khanna
Post published:August 18, 2016
Post category:FOSSASIA GSoC
Post comments:0 Comments

In one of my previous blog posts here, I talked about the Upgrade process of Wordpress, how it works. In this blog, I am going to talk about how I implement the Auto-upgrade feature in Engelsystem. The Upgrade process implemented in Engelsystem includes both core and child upgrades. Methodology: A Verison.txt file in included in the repository. It contains the version number of the current release of the Engelsystem. Implemented a check in index.php to compare the version number in the local repository and the `fossasia/engelsystem` repository. In Engelsystem index.php is run every time when we open the System. Therefore, everytime we open Engelsystem, it automatically checks for updates. if ($check_autoupdate_enable == true) { $online_ver = file_get_contents("https://raw.githubusercontent.com/fossasia/engelsystem/master/Version.txt"); $current_ver = file_get_contents(" ./Version.txt"); if (strcmp($current_ver, $online_ver) != 0) { return info('<a href="' . page_link_to("user_settings") . '">' . _('There is an Update available on GitHub! Go to settings and update') . '</a>', true); } } The above code compares the version number in the local server and the fossasia repository. If the version number is different a notification in displayed in the alert box the Engelsystem to the Admin, to update the system. In the Settings page, Admin can update the System as shown in the screenshot below, The admin can click on the "Update System Now!", to update the system to the latest version. The is also an option provided in the UI to enable/disable the Auto-update feature. When the version in the Version.txt on local server and fossasia repository are different, the changes the pulled to the local server using the command: git pull origin master , which will pull the changes from the FOSSASIA repository to the local server, and a Message will be displayed that the "System is Updated to Latest Version!" . Also, there is an option in the UI to check to Updates manually. We are developing new Features for the Engelsystem. Developers who are interested in contributing can work with us. Development: https://github.com/fossasia/engelsystem Issues/Bugs:https://github.com/fossasia/engelsystem/issues

Unit Testing and Travis

Post author:Dishant Khanna
Post published:August 14, 2016
Post category:FOSSASIA GSoC
Post comments:0 Comments

Tests are an important part of any software development process. We need to write test codes for any feature that we develop to check if that feature is working properly. In this post, I am gonna talk about writing Unit tests and running those test codes. If you are a developer, I assume you have heard about unit tests. Most of you probably even wrote one in your life. Unit testing is becoming more and more popular in software development. Let's first talk about what Unit testing is: What is unit testing? Unit testing is the process through which units of source code are tested to verify if they work properly. Performing unit tests is a way to ensure that all functionalities of an application are working as they should. Unit tests inform the developer when a change in one unit interferes with the functionality of another. Modern unit testing frameworks are typically implemented using the same code used by the system under test. This enables a developer who is writing application code in a particular language to write their unit tests in that language as well. What is a unit testing framework? Unit testing frameworks are developed for the purpose of simplifying the process of unit-testing. Those frameworks enable the creation of Test Fixtures, which are classes that have specific attributes enabling them to be picked up by a Test Runner. Although it is possible to perform unit tests without such a framework, the process can be difficult, complicated and very manual. There are a lot of unit testing frameworks available. Each of the frameworks has its own merits and selecting one depends on what features are needed and the level of expertise of the development team. For my project, Engelsystem I choose PHPUnit as the testing framework. PHPUnit With PHPUnit, the most basic thing you’ll write is a test case. A test case is just a term for a class with several different tests all related to the same functionality. There are a few rules you’ll need to worry about when writing your cases so that they’ll work with PHPUnit: The test class would extend the PHPUnit_Framework_TestCase class. The test parameters will never receive any parameters. Below is an example of a test code from my project, Engelsystem <?php class ShiftTypes_Model_test extends PHPUnit_Framework_TestCase { private $shift_id = null; public function create_ShiftType(){ $this->shift_id = ShiftType_create('test', '1', 'test_description'); } public function test_ShiftType_create() { $count = count(ShiftTypes()); $this->assertNotFalse(create_ShiftType($shift_id)); // There should be one more ShiftTypes now $this->assertEquals(count(ShiftTypes()), $count + 1); } public function test_ShiftType(){ $this->create_ShiftType(); $shift_type = ShiftType($this->shift_id); $this->assertNotFalse($shift_type); $this->assertTrue(count(ShiftTypes()) > 0); $this->assertNotNull($shift_type); $this->assertEquals($shift_type['name'], 'test'); $this->assertEquals(count(ShiftTypes()), 0); $this->assertNull(ShiftTypes(-1)); } public function teardown() { if ($this->shift_id != null) ShiftType_delete($this->shift_id); } } ?> We can use different Assertions to test the functionality. We are running these tests on Travis-CI What is Travis-CI? Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted on GitHub. Open source projects may be tested at no charge via travis-ci.org. Private projects may be tested at…

Creating New Groups in Engelsystem

Post author:Dishant Khanna
Post published:August 6, 2016
Post category:FOSSASIA GSoC
Post comments:0 Comments

User roles determine the access level or permissions of a person authorized (by an Administrator) to use the Engelsystem. If a user (other than admin) have access to only a specific set of pages and features that are assigned to the Group to which the user belongs. Summary In Engelsystem, the Privileges to specific pages and features can be set through GroupRights. There are initially 7 groups present in the Engelsystem namely: Guest Engel Shift Coordinator Team Co-ordinator Burokrat Developer Shirt Manager Each user role is capable of everything that a less powerful role is capable of. All of these 7 groups have different Privileges assigned to them. When a user registers on Engelsystem, it is initially assigned to Group-2 i.e Engel by default, then admin can add a user to different groups according to the requirements. Problem There was a problem with this feature. Bug: https://github.com/fossasia/engelsystem/issues/22 If the user was added to the group with some Admin Privileges, he/she was able to sign up for restricted shifts as well. Solution Added a new page to Engelsystem for creating new Groups with specific privileges which can be that can be provided by the Admin to that group. New groups can be created by Admin, with default Privileges set to privileges as provided to the Engel group.These Privileges can be set while creating a group or can be edited in the GroupRights shown as follow: The group is successfully created and can be viewed in GroupRights page, where the Admin can edit the Privileges of this and the other groups. Providing Privileges to user other than Admin is important as it ease the workload of admin, plus there'll be other users who'll be handling different tasks in an Event which is important in managing an Event. We are developing new feature for Engelsystem and we will be applying this WordPress like update system toEngelsystem in the upcoming weeks. Developers who are interested in contributing can work with us. Development: https://github.com/fossasia/engelsystem Issues/Bugs:https://github.com/fossasia/engelsystem/issues

Implementing MVC on Engelsystem

Post author:Dishant Khanna
Post published:July 28, 2016
Post category:FOSSASIA GSoC

Engelsystem is an MVC based PHP application, but there was a 4th ties, Pages, introduced with the traditional MVC pattern. It seems to have everything an event manager could want. The Model-View-Control (MVC) pattern, originally formulated in the late 1970s, is a software architecture pattern built on the basis of keeping the presentation of data separate from the methods that interact with the data. In theory, a well-developed MVC system should allow a front-end developer and a back-end developer to work on the same system without interfering, sharing, or editing files either party is working on. Like everything else in software engineering, it seems, the concept of Model-View-Controller was originally invented bySmalltalk programmers. More specifically, it was invented by one Smalltalk programmer, Trygve Reenskaug. Trygve maintains a page that explains the history of MVC in his own words. The components of an MVC pattern are explained as follows: MODEL: The Model is the name given to the permanent storage of the data used in the overall design. Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. VIEW: The View is where data, requested from the Model, is viewed and its final output is determined. A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter. Traditionally in web apps built using MVC, the View is the part of the system where the HTML is generated and displayed. The View also ignites reactions from the user, who then goes on to interact with the Controller. CONTROLLER: The final component of the triad is the Controller.A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. Its job is to handle data that the user inputs or submits, and update the Model accordingly. The Controller’s life blood is the user; without user interactions, the Controller has no purpose. Even though MVC was originally designed for personal computing, it has been adapted and is widely being used by web developers due to its emphasis on separation of concerns, and thus indirectly, reusable code. The pattern encourages the development of modular systems, allowing developers to quickly update, add, or even remove functionality. Initially, in Engelsystem there were files distributed in 4 tiers, Model, View, Controller, Pages, which are mentioned as follows: Pages: admin_active.php admin_arrive.php admin_export.php admin_free.php admin_groups.php admin_import.php admin_log.php admin_news.php admin_questions.php admin_rooms.php admin_settings.php admin_shifts.php admin_user.php guest_credits.php guest_login.php guest_start.php guest_stats.php user_atom.php user_ical.php user_messages.php user_myshifts.php user_news.php user_questions.php user_settings.php user_shifts.php Model: AngelType_model.php LogEntries_model.php Message_model.php NeededAngelTypes_model.php Room_model.php Settings_model.php ShiftEntry_model.php ShiftTypes_model.php Shifts_model.php UserAngelTypes_model.php UserDriverLicenses.model.php User_model.php Controller angeltype_controller.php rooms_controller.php shifts_controller.php shifttypes_controller.php user_angeltypes_controller.php user_driver_licenses_controller.php user_controller.php View AngelTypes_view.php Questions_view.php Rooms_view.php ShiftEntry_view.php ShiftTypes_view.php Shifts_view.php UserAngelTypes_view.php UserDriverLicenses_view.php User_view.php There were 26 Pages files, in which there were both sql queries along with the controller code. All these files were refactured into Controller and Model(which contains sql queries)…

WordPress Upgrade Process

Post author:Dishant Khanna
Post published:July 19, 2016
Post category:FOSSASIA GSoC

Have you ever wondered how Wordpress handles the automated core, plugin, and theme upgrades? Well, it’s time for some quick education! WordPress is an Open Source project, which means there are hundreds of people all over the world working on it. (More than most commercial platforms.) There are mainly 2 kinds of Automatic upgrades for Wordpress: The main 'Core' upgrades The 'Child' upgrades, that works for themes and plugins that are being used in your Wordpress. We all see the plugin and theme installer while installing any theme or specific plugin required by the user, where it downloads the plugin to /wp-content/upgrade/ , extracts the plugin, deletes the old one (if an old one exists), and copies the new one. It is used every time we install a theme or a plugin to the Wordpress. Since this is used more often than the core updater (most of the time as many different plugins are used), it’s the sort of upgrade we’re all used to and familiar with. And we think ‘WordPress deletes before upgrading, sure.’ This makes sense. After all, you want to make sure to clean out the old files, especially the ones that aren’t used anymore. But that not how the Wordpress Core updates work. Core updates are available when there is a new version of Wordpress is available with new features or some solved bugs. Core updates are subdivided into three types: Core development updates, known as the "bleeding edge" Minor core updates, such as maintenance and security releases Major core release updates By default, every site has automatic updates enabled for minor core releases and translation files. Sites already running a development version also have automatic updates to further development versions enabled by default. The Wordpress updates can be configured by 2 ways: defining constants in wp-config.php, or adding filters using a Plugin Let's discuss for both the methods. Configuration via wp-config.php We can configure the wp-config.php to, disable automatic updates, and the core updates can be disabled or configured based on update type. To completely disable all types of automatic updates, core or otherwise, add the following to your wp-config.php file: define( 'AUTOMATIC_UPDATER_DISABLED', true ); To enable automatic updates for major releases or development purposes, the place to start is with the WP_AUTO_UPDATE_CORE constant. Defining this constant one of three ways allows you to blanket-enable, or blanket-disable several types of core updates at once. define( 'WP_AUTO_UPDATE_CORE', true ); WP_AUTO_UPDATE_CORE can be defined with one of three values, each producing a different behavior: Value of true – Development, minor, and major updates are all enabled Value of false – Development, minor, and major updates are all disabled Value of 'minor' – Minor updates are enabled, development, and major updates are disabled Configuration via Filters using Plugins Using filters allows for fine-tuned control of automatic updates. The best place to put these filters is a must-use plugin. Do not add add_filter() calls directly in wp-config.php. WordPress isn't fully loaded and can cause conflicts with other applications such as WP-CLI. We can also enable/disable all automatic updates by changing…

Read and Understand Codacy Reports

Post author:Dishant Khanna
Post published:July 16, 2016
Post category:FOSSASIA GSoC

To begin understanding reports, let's start with what Codacy is. So. What is Codacy? Codacy is an automated code review tool that helps developers to save time in code reviews and to tackle technical debt. It centralises customizable code patterns and enforces them within engineering teams. Codacy tracks new issues by severity level for every commit and pull request. It can be integrated with the GitHub repository to review every commit and pull request in terms of quality and errors. It checks code style, security, duplication, complexity and coverage on every change while tracking code quality throughout your sprints. You can integrate Codacy in your private/public repository by going here. Sign up with your Github account and follow the steps mentioned. More information regarding GitHub integration can be found here. Features of Codacy: SAVE TIME IN CODE REVIEWS INTEGRATED IN YOUR WORKFLOW TRACK YOUR PROJECT QUALITY EVOLUTION Now we get to understanding Codacy reports. Below shows and image of how a Codacy dashboard looks like, to evaluate a project. To evaluate a project we should know what are the "Software Metrics". A software metric is a standard of measure of a degree to which a software system or process possesses some property. Even if a metric is not a measurement (metrics are functions, while measurements are the numbers obtained by the application of metrics), often the two terms are used as synonymous. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in the schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments. You can learn about software metrics by visiting here. A Codacy Dashboard provides answer to the following 3 main things: What is the state of your projects code quality? How is it evolving throughout time? What are the hotspots in your code? Component of the Dashboard: Introduction: The Dashboard is the central screen of any project on Codacy. Project Certification: After running a complete on the project or the GitHub repository, Codacy provides an overall grade to the project from A-F. The grade depends on the following parameters. Error Prone Code Complexity Code Style Unused Code Security Compatibility Documentation Performance Issues Breakdown: Issues breakdown represents the different issues from different areas in a pictorial representation. It provides a quick overview of the total number of issues in the repository and the breakdown per category. Users can click on the specific category for more details. Code Coverage: If you setup the code coverage on your repository, you will be able to see the overall covered percentage on the dashboard. It will also show the files with the worst code coverage allowing you to directly jump to the file to see the details. Goals: Users can define individual goals to remove errors and get better grades for their projects. Historic data: Codacy dashboard also provides an analysis of the Historic data,…

Continuous Integration and Automated Testing for Engelsystem

Post author:Dishant Khanna
Post published:July 3, 2016
Post category:FOSSASIA GSoC

Every software development group tests its products, yet delivered software always has defects. Test engineers strive to catch them before the product is released but they always creep in and they often reappear, even with the best manual testing processes. Using automated testing is the best way to increase the effectiveness, efficiency and coverage of your software testing. Manual software testing is performed by a human sitting in front of a computer carefully going through application screens, trying various usage and input combinations, comparing the results to the expected behavior and recording their observations. Manual tests are repeated often during development cycles for source code changes and other situations like multiple operating environments and hardware configurations. Continuous integration (CI) has emerged as one of the most efficient ways to develop code. But testing has not always been a major part of the CI conversation. In some respects, that’s not surprising. Traditionally, CI has been all about speeding up the coding, building, and release process. Instead of having each programmer write code separately, integrate it manually, and then wait until the next daily or weekly build to see if the changes broke anything, CI lets developers code and compile on a virtually continuous basis. It also means developers and admins can work together seamlessly since the programming and build processes are always in sync. Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. By integrating regularly, you can detect errors quickly, and locate them more easily. Solve problems quickly Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features. Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether. Continuous Integration brings multiple benefits to your organization: Say goodbye to long and tense integrations Increase visibility which enables greater communication Catch issues fast and nip them in the bud Spend less time debugging and more time adding features Proceed with the confidence you’re building on a solid foundation Stop waiting to find out if your code’s going to work Reduce integration problems allowing you to deliver software more rapidly “Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” - Martin Fowler, Chief Scientist, ThoughtWorks Continuous Integration is backed by several important principles and practices. Practices in Continuous Integration: Maintain a single source repository Automate the build Make your build self-testing Every commit should build on an integration machine Keep the build fast Test in a clone of the production environment Make it easy for anyone to get the latest executable Everyone can see what’s…

Implementing Captcha for Engelsystem

Post author:Dishant Khanna
Post published:June 26, 2016
Post category:FOSSASIA

Knock, knock. Who’s there? A spam bot. If you’re a web administrator or website owner, then you are bound to know the ugly truth that is the Spam Bot. Someone, somewhere in the world must have made a deal with the Devil in hopes of a larger payout that didn’t exactly pan out the way they. The goal of the volunteer system (Engelsystem) is to facilitate the work of event organizers and event volunteers. It would be creating problems if bots signup for shifts and fill all the vacancies. Thanks to the mastermind behind them, those pesky little underlings crawl the web ready to cause mischief at every turn. This means more work and more time eaten up for the honest web admin/event organizer who is left to clean up the mess left in their wake. What Is CAPTCHA? CAPTCHAs are nothing new to the experienced web surfer. Sites/web apps, both large and small, use the system for one reason or another. But, ever wonder where in the world the people who coined the phrase, CAPTCHA, came up with that nonsensical name? Well, you may find it interesting to know that the strange word is actually a clever acronym meaning the following: Completely Automated Public Test to tell Computers and Humans Apart. What a mouthful! Now aren’t you happy that they shortened it? The actual meaning of the word essentially explains exactly what its purpose is: keeping pesky bots out and letting in well-meaning humans (or at least that is the hope). We worked on implementing Google reCaptcha to the registration form and to the shifts signup page. On websites using this new API, a significant number of users will be able to securely and easily verify they’re human without actually having to solve a CAPTCHA. Instead, with just a single click, they’ll confirm they are not a robot. Client-side integration: if (isset($_REQUEST['g-recaptcha-response']) && !empty($_REQUEST['g-recaptcha-response'])) { $curl = curl_init(); curl_setopt_array($curl, [ CURLOPT_RETURNTRANSFER => 1, CURLOPT_URL => 'hppts://www.google.com/recaptcha/api/siteverify', CURLOPT_POST => 1, CURLOPT_POSTFIELDS => [ 'secret' => '', // Enter your private key here. 'response' => $_REQUEST['g-recaptcha-response'], ] ]); $response = json_decode(curl_exec($curl)); $msg .= error(sprintf(_(print_r($response)), $nick), true); } else { $ok = false; $msg .= error(_("You are a Robot."), true); } } If the System is hosted on an online server, the user needs to register and get the API keys for implementing Google reCaptcha here. Final Thoughts Spam is a big issue for all websites, including sites ran on WordPress. Although CAPTCHA forms don’t completely eliminate spam mongers, when you use it with other popular spam blocking plugins like Akismet, you really do have the advantage on the spam bot battlefield. Development: https://github.com/fossasia/engelsystem Issues/Bugs:https://github.com/fossasia/engelsystem/issues

Why Coding Standards Matter

Post author:Dishant Khanna
Post published:June 17, 2016
Post category:FOSSASIA

Coding standards are a set of guidelines, best practices, programming styles and conventions that developers adhere to when writing source code for a project. All big software companies have them. A coding standards document tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to the standards outlined in the document. This makes sure that a large project is coded in a consistent style — parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application. When you start sharing code or start reading code shared by others, you begin to realize that not everybody writes their code they way you do. You see that other, ugly coding style, and think “everybody needs to write in the same style so that things are easier for me to understand.” Thus, it is natural that everybody wants their own habits turned into the standard, so they don’t have to change their habits. They’re used to reading code a certain way (their own way) and get irritated when they see the code in a different format. The thing about defining a coding style standard is that there are no objective means by which to judge one style as “better” or “more-right” than another. Sure, we can talk about “readability” and “consistency” but what is readable is different for each coder (depending on what they’re used to) and consistency follows automatically because, well, why would you use another style? Other than in the broadest outlines, defining a coding standard is an exercise in arbitrariness. Who says that a 75 character line is better than 72, or 80? Who says putting braces in one place is better than putting them elsewhere? And who are they to say; by what standard do they judge? The point of a coding style standard is not to say one style is objectively better than another in the sense of the specific details (75 characters and one-true-brace convention, for example). Instead, the point is to set up known expectations on how code is going to look. For example, my project Engelsystem,it is a project written by more than one person. If you examine some Script A and see one coding style, then examine Script B and see another, the effect is very jarring; they don’t look like they belong to the same project. Similarly, when I, a Developer, (who uses one coding style) attempts to patch or add to a separate project from other Developer (who uses another coding style) the mix-and-match result in the same project (or even the same file!) is doubly jarring. Another example that I can think of: a manager who insisted on being part of every major code review. During the reviews, he would flag formatting issues, that were almost always a matter of his own…