DOCSLIB.ORG

The Importance of Coding Styles Within Industries Stijn Broekhuis University of Twente P.O

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Importance of Coding Styles Within Industries Stijn Broekhuis University of Twente P.O The Importance of Coding Styles within Industries Stijn Broekhuis University of Twente P.O. Box 217, 7500AE Enschede The Netherlands [email protected] ABSTRACT with camelCase [10, 13, 15,5]. However, in Python this There exist common conventions and styles that try to im- is often snake_case [17,5] which originates from the lan- prove the readability and maintainability of software code. guage C. It is common for industrial projects to work with these Besides different coding styles between languages, many coding practices. Teams adopt or adapt coding styles, IDEs (Integrated development environment) offer options and in some cases, they are mandatory. This means cod- to change these styles to fit the preference of the user. ing practices are an integral part of software development. When a project involves multiple people it can then result This research will try to find a greater understanding of in every user having their own coding styles. To solve this coding styles within industries. Firstly, a literature review problem a there exists a file format called .editorconfig1. of coding styles with non-semantic consequences and their Many IDEs allow their coding style settings to be over- effects was done. Then, a survey was used to find informa- written by a file named .editorconfig that is stored in a tion about how coding styles are used in companies and project. Since the file is within a project, all members of finding a difference in the coding styles by looking at the the project will have the same .editorconfig file and thus experience. Nearly all participants used coding styles such maintain a consistent coding style (because their IDEs will as Naming Conventions, Brackets and Indention rules. warn or even cause errors if they do not). To manage and fix bugs within code, it must be read- Keywords able. It is known that some coding practices affect the readability of code [1,2,8] in both positive and nega- Coding Conventions, Coding Styles, Programming tive ways. For a company it is useful to have conventions that improve the readability of their code. Coding styles 1. INTRODUCTION with non-semantic consequences are styles that do not af- The skills of a good programmer are not something to fect how the code operates, it only affects how code looks. be taught. Learning to write good code is achieved often This study focuses on the non-semantic consequences as by starting with reading good code. Making code read- it interesting to see the reason why they are used. Other able is, therefore, an important factor in programming. styles that have semantic consequences are useful as they Besides being able to make better code, readable code is can improve the code's speed, testability, maintainability, essential for programmers that work in a team to work to- or debugability. It is expected that developers in indus- gether. As everyone needs to be able to understand what tries have higher standards for clean code than a project sections of code do without spending too much time. As made by a single person. The goals for this research are a result, coding conventions and styles were made. One as follows: of the first coding standards is the book "The Elements of Programming Style" [6] written by Kernighan, Brian W. Goal 1: Develop a greater understanding of the effects of and Plauger, Phillip James. The book showed examples coding conventions and the common differences in of real programs and how they could be improved. Many popular languages. of the 'lessons' that Kernighan and Plauger stated, such as; Say what you mean, simply and directly. and Write Goal 2: Develop a greater understanding of the impor- clearly - don't sacrifice clarity for "efficiency." are still rel- tance and usage of coding styles with non-semantic evant today. consequences in industries. Coding styles such as the location of a 'f' or using spaces To achieve these goals, the following research questions around operations, do not have an objective reason why (RQ) are used as a basis: some are better than others. These are often based on preference and what is common in the language. In Java, the naming conventions of variables are usually written RQ1: In what areas do non-semantic coding styles differ in popular languages such as Java, Python, JavaScript Permission to make digital or hard copies of all or part of this work for and C#? personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that RQ2: How do non-semantic coding styles found in RQ1 copies bear this notice and the full citation on the first page. To copy oth- influence the quality/readability of the code? erwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. RQ3: How do employees of industries use coding styles 35th Twente Student Conference on IT July. 2nd, 2021, Enschede, The found in RQ1? Are they aware of the influences Netherlands. found in RQ2? Copyright 2021, University of Twente, Faculty of Electrical Engineer- 1 ing, Mathematics and Computer Science. Learn more: https://editorconfig.org/ 1 This study conducted literature research and a survey to of individual coding styles. This will give an understand- find out how coding styles are generally used. The sur- ing of the importance of individual coding conventions and vey will ask employees what coding styles and conventions styles. Answering this question allows the research to con- they use and their experience and opinion about using tinue with the next and final research question. them. The results will give insight into the frequency and RQ3 will be answered with a survey that will be given to necessity of coding practices and how they are executed. employees of different industries using Google Forms. The survey will have three sections. Firstly, general questions 2. RELATED WORK about what type of work they work in, how long they have This section contains related work about coding conven- worked, and what language they work in. Secondly, this tions. Coding conventions have been proposed since the section will focus on questions about coding styles. These 1970s. Well known examples are authors are Kernighan coding styles will not be connected to specific languages. and Plauger. Most papers focused on semantic conse- Thirdly, there will be a section about coding conventions quences, although some did partly focused on readability. and their effect on the quality of code according to the par- In 1974, Kernighan, Brian W. and Plauger, Phillip James ticipants. Finally, with the answers found in the research [6] published the first edition of The Elements of Program- questions, the goals will be completed and a conclusion for ming Style. According to them, it has been common for each of them can be made. programmers to make unreadable code that was a pain to maintain, so-called 'write-only code', but "...students, 4. THE CODING STYLES teachers, and computing professionals now recognize the To find common areas that coding styles differ, one has importance of readable programs." The book gave many to look at coding style guides. The research found cod- lessons on how to write quality code by using examples of ing guidelines by using the search engines DuckDuckGo real software and improving them. and Google and using the terms "Coding Style Guide" and In 2016, H. G. Koller [7] wrote in their master thesis about "Coding Conventions Guides". Six guides were chosen. the effects of Clean Code on understandability. Their re- These were based on the most used languages [4]. Using search showed, unexpectedly, little effect on the under- six guidelines gives an accurate representation of popular standability when using Clean Code. Using Clean Code languages and what areas coding styles are often used. only had a positive effect on how long changing current Google Style Guides functionality took. The Google Styles Guides [5] are a collection of style guides In 2018, R. M. dos Santos and M. A. Gerosa [2] experi- that are used by Google and serve as a guide for program- mented with certain coding practices and the impact on mers within the company who add to Google's code or for the readability of the code. Their research found that of external programmers who wish to create a project that the 11 assessed coding practices they tested, 8 had evi- has the same style as Google. Because this is a collection dence that it affected readability. of style guides, the study looked at the style guide of pop- ular languages[4]. Unlike humans, the style guides have In 2021, V. Lenarduzzi, V. Nikkola, N. Saarim¨aki and D. Taibi [9] researched the effects of code quality on pull re- similar reasons for their existence. They help program- quest acceptance. They wanted to find out if GitHub pull mers to make code readable and/or look better. However, requests had a higher chance of being accepted if the code these are not rules, one is not required to follow them. If was clean. They concluded that code quality does not there is a scenario where violating the guidelines results in affect the pull request acceptance. better code, then these rules do not apply. Additionally, style guides might be wrong on certain rules and forcing is therefore not a favourable idea. 3. RESEARCH METHODOLOGIES Answers to the research questions mentioned above need Style Guide for Python Code 2001 to be found to achieve the goal of the paper. In Figure1 The Style Guide for Python Code [17] is part of the Python is a simple diagram of how the research questions relate.
Load more

Recommended publications
  • Java Programming Standards & Reference Guide
    Java Programming Standards & Reference Guide Version 3.2 Office of Information & Technology Department of Veterans Affairs Java Programming Standards & Reference Guide, Version 3.2 REVISION HISTORY DATE VER. DESCRIPTION AUTHOR CONTRIBUTORS 10-26-15 3.2 Added Logging Sid Everhart JSC Standards , updated Vic Pezzolla checkstyle installation instructions and package name rules. 11-14-14 3.1 Added ground rules for Vic Pezzolla JSC enforcement 9-26-14 3.0 Document is continually Raymond JSC and several being edited for Steele OI&T noteworthy technical accuracy and / PD Subject Matter compliance to JSC Experts (SMEs) standards. 12-1-09 2.0 Document Updated Michael Huneycutt Sr 4-7-05 1.2 Document Updated Sachin Mai L Vo Sharma Lyn D Teague Rajesh Somannair Katherine Stark Niharika Goyal Ron Ruzbacki 3-4-05 1.0 Document Created Sachin Sharma i Java Programming Standards & Reference Guide, Version 3.2 ABSTRACT The VA Java Development Community has been establishing standards, capturing industry best practices, and applying the insight of experienced (and seasoned) VA developers to develop this “Java Programming Standards & Reference Guide”. The Java Standards Committee (JSC) team is encouraging the use of CheckStyle (in the Eclipse IDE environment) to quickly scan Java code, to locate Java programming standard errors, find inconsistencies, and generally help build program conformance. The benefits of writing quality Java code infused with consistent coding and documentation standards is critical to the efforts of the Department of Veterans Affairs (VA). This document stands for the quality, readability, consistency and maintainability of code development and it applies to all VA Java programmers (including contractors).
    [Show full text]
  • Devsecops in Reguated Industries Capgemini Template.Indd
    DEVSECOPS IN REGULATED INDUSTRIES ACCELERATING SOFTWARE RELIABILITY & COMPLIANCE TABLE OF CONTENTS 03... Executive Summary 04... Introduction 07... Impediments to DevSecOps Adoption 10... Playbook for DevSecOps Adoption 19... Conclusion EXECUTIVE SUMMARY DevOps practices enable rapid product engineering delivery and operations, particularly by agile teams using lean practices. There is an evolution from DevOps to DevSecOps, which is at the intersection of development, operations, and security. Security cannot be added after product development is complete and security testing cannot be done as a once-per-release cycle activity. Shifting security Left implies integration of security at all stages of the Software Development Life Cycle (SDLC). Adoption of DevSecOps practices enables faster, more reliable and more secure software. While DevSecOps emerged from Internet and software companies, it can benefit other industries, including regulated and high security environments. This whitepaper covers how incorporating DevSecOps in regulated Industries can accelerate software delivery, reducing the time from code change to production deployment or release while reducing security risks. This whitepaper defines a playbook for DevSecOps goals, addresses challenges, and discusses evolving workflows in DevSecOps, including cloud, agile, application modernization and digital transformation. Bi-directional requirement traceability, document generation and security tests should be part of the CI/CD pipeline. Regulated industries can securely move away
    [Show full text]
  • "This Book Was a Joy to Read. It Covered All Sorts of Techniques for Debugging, Including 'Defensive' Paradigms That Will Eliminate Bugs in the First Place
    Perl Debugged By Peter Scott, Ed Wright Publisher : Addison Wesley Pub Date : March 01, 2001 ISBN : 0-201-70054-9 Table of • Pages : 288 Contents "This book was a joy to read. It covered all sorts of techniques for debugging, including 'defensive' paradigms that will eliminate bugs in the first place. As coach of the USA Programming Team, I find the most difficult thing to teach is debugging. This is the first text I've even heard of that attacks the problem. It does a fine job. Please encourage these guys to write more." -Rob Kolstad Perl Debugged provides the expertise and solutions developers require for coding better, faster, and more reliably in Perl. Focusing on debugging, the most vexing aspect of programming in Perl, this example-rich reference and how-to guide minimizes development, troubleshooting, and maintenance time resulting in the creation of elegant and error-free Perl code. Designed for the novice to intermediate software developer, Perl Debugged will save the programmer time and frustration in debugging Perl programs. Based on the authors' extensive experience with the language, this book guides developers through the entire programming process, tackling the benefits, plights, and pitfalls of Perl programming. Beginning with a guided tour of the Perl documentation, the book progresses to debugging, testing, and performance issues, and also devotes a chapter to CGI programming in Perl. Throughout the book, the authors espouse defensible paradigms for improving the accuracy and performance of Perl code. In addition, Perl Debugged includes Scott and Wright's "Perls of Wisdom" which summarize key ideas from each of the chapters, and an appendix containing a comprehensive listing of Perl debugger commands.
    [Show full text]
  • A Style Guide
    How to Program Racket: a Style Guide Version 6.11 Matthias Felleisen, Matthew Flatt, Robby Findler, Jay McCarthy October 30, 2017 Since 1995 the number of “repository contributors” has grown from a small handful to three dozen and more. This growth implies a lot of learning and the introduction of inconsistencies of programming styles. This document is an attempt leverage the former and to start reducing the latter. Doing so will help us, the developers, and our users, who use the open source code in our repository as an implicit guide to Racket programming. To help manage the growth our code and showcase good Racket style, we need guidelines that shape the contributions to the code base. These guidelines should achieve some level of consistency across the different portions of the code base so that everyone who opens files can easily find their way around. This document spells out the guidelines. They cover a range of topics, from basic work (commit) habits to small syntactic ideas like indentation and naming. Many pieces of the code base don’t live up to the guidelines yet. Here is how we get started. When you start a new file, stick to the guidelines. If you need to edit a file, you will need to spend some time understanding its workings. If doing so takes quite a while due to inconsistencies with the guidelines, please take the time to fix (portions of) the file. After all, if the inconsistencies throw you off for that much time, others are likely to have the same problems.
    [Show full text]
  • Coding Style Guidelines
    Coding Style Guidelines Coding Style Guidelines Introduction This document was created to provide Xilinx users with a guideline for producing fast, reliable, and reusable HDL code. Table of Contents Top-Down Design ⎯ Section 1 ................................................................13-4 Behavioral and Structural Code...................................................................13-4 Declarations, Instantiations, and Mappings.................................................13-5 Comments ...................................................................................................13-6 Indentation...................................................................................................13-9 Naming Conventions ...................................................................................13-10 Signals and Variables ⎯ Section 2..........................................................13-13 Signals.........................................................................................................13-13 Casting.........................................................................................................13-13 Inverted Signals...........................................................................................13-13 Rule for Signals ...........................................................................................13-14 Rules for Variables and Variable Use .........................................................13-15 Packages ⎯ Section 3 ..............................................................................13-17
    [Show full text]
  • Coding Style
    Coding Style by G.A. (For internal Use Only. Do not distribute) April 23, 2018 1 Organizational 1.1 Codes and Automation Codes to which these rules apply are the following. DMRG++, PsimagLite, Lanczos++, FreeFermions, GpusDoneRight, SPFv7, and MPS++. The script indentStrict.pl can be used to automate the application of these rules, as shown in Listing1, where the option -fix will fix most problems in place. Listing 1: Use of the indentStrict.pl script. PsimagLite/scripts/indentStrict.pl -file file.h [-fix] 1.2 Indentation Indent using “hard” tabs and Kernighan and Ritchie indentation. This is the indentation style used by the Linux Kernel. Note that the tab character is octal 011, decimal 9, hex. 09, or “nt” (horizontal tab). You can represent tabs with any number of spaces you want. Regardless, a tab is saved to disk as a single character: hex. 09, and *not* as 8 spaces. When a statement or other line of code is too long and follows on a separate line, do not add an indentation level with tab(s), but use spaces for aligment. For an example see Listing2, where tabs (indentation levels) are indicated by arrows. Listing 2: Proper use of continuation lines. class␣A␣{ −−−−−−−!void␣thisIsAVeryVeryLongFunction(const␣VeryVeryLongType&␣x, −−−−−−−!␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣const␣VeryVeryLongType&␣y) −−−−−−−!{ −−−−−−−→−−−−−−−!//␣code␣here −−−−−−−!} I repeat the same thing more formally now: Indent following the Linux coding style, with exceptions due to the Linux style applying to C, but here we’re talking about code written in C++. 1. Classes are indented like this: 1 1.2 Indentation class A { }; That is, they are indented as for loops and not as functions.
    [Show full text]
  • Advanced Tcl E D
    PART II I I . A d v a n c Advanced Tcl e d T c l Part II describes advanced programming techniques that support sophisticated applications. The Tcl interfaces remain simple, so you can quickly construct pow- erful applications. Chapter 10 describes eval, which lets you create Tcl programs on the fly. There are tricks with using eval correctly, and a few rules of thumb to make your life easier. Chapter 11 describes regular expressions. This is the most powerful string processing facility in Tcl. This chapter includes a cookbook of useful regular expressions. Chapter 12 describes the library and package facility used to organize your code into reusable modules. Chapter 13 describes introspection and debugging. Introspection provides information about the state of the Tcl interpreter. Chapter 14 describes namespaces that partition the global scope for vari- ables and procedures. Namespaces help you structure large Tcl applications. Chapter 15 describes the features that support Internationalization, includ- ing Unicode, other character set encodings, and message catalogs. Chapter 16 describes event-driven I/O programming. This lets you run pro- cess pipelines in the background. It is also very useful with network socket pro- gramming, which is the topic of Chapter 17. Chapter 18 describes TclHttpd, a Web server built entirely in Tcl. You can build applications on top of TclHttpd, or integrate the server into existing appli- cations to give them a web interface. TclHttpd also supports regular Web sites. Chapter 19 describes Safe-Tcl and using multiple Tcl interpreters. You can create multiple Tcl interpreters for your application. If an interpreter is safe, then you can grant it restricted functionality.
    [Show full text]
  • The Pascal Programming Language
    The Pascal Programming Language http://pascal-central.com/ppl/chapter2.html The Pascal Programming Language Bill Catambay, Pascal Developer Chapter 2 The Pascal Programming Language by Bill Catambay Return to Table of Contents II. The Pascal Architecture Pascal is a strongly typed, block structured programming language. The "type" of a Pascal variable consists of its semantic nature and its range of values, and can be expressed by a type name, an explicit value range, or a combination thereof. The range of values for a type is defined by the language itself for built-in types, or by the programmer for programmer defined types. Programmer-defined types are unique data types defined within the Pascal TYPE declaration section, and can consist of enumerated types, arrays, records, pointers, sets, and more, as well as combinations thereof. When variables are declared as one type, the compiler can assume that the variable will be used as that type throughout the life of the variable (whether it is global to the program, or local to a function or procedure). This consistent usage of variables makes the code easier to maintain. The compiler detects type inconsistency errors at compile time, catching many errors and reducing the need to run the code through a debugger. Additionally, it allows an optimizer to make assumptions during compilation, thereby providing more efficient executables. As John Reagan, the architect of Compaq Pascal, writes, "it was easy to write Pascal programs that would generate better code than their C equivalents" because the compiler was able to optimize based on the strict typing.
    [Show full text]
  • Application Note C/C++ Coding Standard
    Application Note C/C++ Coding Standard Document Revision J April 2013 Copyright © Quantum Leaps, LLC www.quantum-leaps.com www.state-machine.com Table of Contents 1 Goals..................................................................................................................................................................... 1 2 General Rules....................................................................................................................................................... 1 3 C/C++ Layout........................................................................................................................................................ 2 3.1 Expressions................................................................................................................................................... 2 3.2 Indentation..................................................................................................................................................... 3 3.2.1 The if Statement.................................................................................................................................. 4 3.2.2 The for Statement............................................................................................................................... 4 3.2.3 The while Statement........................................................................................................................... 4 3.2.4 The do..while Statement.....................................................................................................................5
    [Show full text]
  • TT284 Web Technologies Block 2 Web Architecture an Introduction to Javascript
    TT284 Web technologies Block 2 Web Architecture An Introduction to JavaScript Prepared for the module team by Andres Baravalle, Doug Briggs, Michelle Hoyle and Neil Simpkins Introduction 3 Starting with JavaScript “Hello World” 3 Inserting JavaScript into Web Pages 3 Editing tools 4 Browser tools 5 Lexical structure of JavaScript 5 Semicolons 6 Whitespace 6 Case sensitivity 6 Comments 7 Literals 8 Variables and data types 8 Variables as space for data 9 Declaring variables and storing values 10 Expressions 11 Operators 11 Assignment operators 11 Arithmetic operators 12 Comparison operators 12 Logical operators 12 String operators 13 Operator precedence 14 Operators and type conversions 15 Debugging JavaScript 16 Statements 17 Copyright © 2012 The Open University TT284 Web technologies Conditional statements 18 Loop statements 19 Arrays 20 Working with arrays 21 Objects 22 Functions 23 Writing functions 24 Variable scope 25 Constructors 26 Methods 27 Coding guidelines 28 Why do we have coding guidelines? 28 Indentation style and layout 28 ‘Optional’ semicolons and ‘var’s 29 Consistent and mnemonic naming 29 Make appropriate comments 30 Reusable code 30 Other sources of information 31 Web resources 31 TT284 Block 2 An Introduction to JavaScript | 2 TT284 Web technologies Introduction This guide is intended as an aid for anyone unfamiliar with basic JavaScript programming. This guide doesn’t include information beyond that required to complete TT284 (there is very little on object orientated coding for example). To use this guide you must be fully familiar with HTML and use of a web browser. For many TT284 students this guide will be unnecessary or will serve perhaps as a refresher on programming after completing a module such as TU100, perhaps some time ago.
    [Show full text]
  • OHD C++ Coding Standards and Guidelines
    National Weather Service/OHD Science Infusion and Software Engineering Process Group (SISEPG) – C++ Programming Standards and Guidelines NATIONAL WEATHER SERVICE OFFICE of HYDROLOGIC DEVELOPMENT Science Infusion Software Engineering Process Group (SISEPG) C++ Programming Standards and Guidelines Version 1.11 Version 1.11 11/17/2006 National Weather Service/OHD Science Infusion and Software Engineering Process Group (SISEPG) – C++ Programming Standards and Guidelines 1. Introduction..................................................................................................................1 2. Standards......................................................................................................................2 2.1 File Names .......................................................................................................2 2.2 File Organization .............................................................................................2 2.3 Include Files.....................................................................................................3 2.4 Comments ........................................................................................................3 2.5 Naming Schemes .............................................................................................4 2.6 Readability and Maintainability.......................................................................5 2.6.1 Indentation ...............................................................................................5 2.6.2 Braces.......................................................................................................5
    [Show full text]
  • Library of Congress Cataloging-In-Publication Data
    Library of Congress Cataloging-in-Publication Data Carrano, Frank M. 39 Data abstraction and problem solving with C++: walls and mirrors / Frank M. Carrano, Janet J. Prichard.—3rd ed. p. cm. ISBN 0-201-74119-9 (alk. paper) 1. C++ (Computer program language) 2. Abstract data types. 3. Problem solving—Data Processing. I. Prichard, Janet J. II. Title. QA76.73.C153 C38 2001 005.7'3—dc21 2001027940 CIP Copyright © 2002 by Pearson Education, Inc. Readability. For a program to be easy to follow, it should have a good structure and design, a good choice of identifiers, good indentation and use of blank lines, and good documentation. You should avoid clever programming tricks that save a little computer time at the expense of much human time. You will see examples of these points in programs throughout the book. Choose identifiers that describe their purpose, that is, are self- documenting. Distinguish between keywords, such as int, and user- defined identifiers. This book uses the following conventions: • Keywords are lowercase and appear in boldface. Identifier style • Names of standard functions are lowercase. • User-defined identifiers use both upper- and lowercase letters, as follows: • Class names are nouns, with each word in the identifier capi- talized. • Function names within a class are verbs, with the first letter lowercase and subsequent internal words capitalized. • Variables begin with a lowercase letter, with subsequent words in the identifier capitalized. • Data types declared in a typedef statement and names of structures and enumerations each begin with an uppercase letter. • Named constants and enumerators are entirely uppercase and use underscores to separate words.
    [Show full text]