As time passes, more and more code is written, and as companies owna large quantity of code, the importance of readable and easy-to-understand codeincreases. It is well known that a developer's time is spent primarily on reading and understanding source code. This study aims to answer the questions: do students and professionals in software development agree on the current state-of-the-art of source code readability, what inhibits developers from writing code with high readability, and what activities they perceive to help them write code with high readability. In this context, readability is defined as the ease with which a person can read, understand, and comprehend source code, and the effort it takes to understand the logic, relations, cohesion, and ideas behind the code. A survey was distributed by email and social media to people working in the field. The respondents were asked to answer questions about readability and three self-evaluating questions about how they work with code. Responses were analyzed and compared to the state-of-the-art in readability of source code.  A literature study was performed to determine the current state-of-the-art of source code readability.The survey result showed considerable support for the findings of the literature review. The survey results also revealed that the most significant inhibitors for writing code with high readability are connected to lack of time, and the most recognized method of increasing readability is code reviews.

Context. There is a need for developers to write clean code and code that adheres to a high-quality standard. We need developers not to introduce technical debt and code smells to the code. From a business perspective, developers that introduce technical debt to the code will make the code more difficult to maintain, meaning that the cost for the project will increase. Objectives. The main objective of this study is to gain an understanding about the perception the developers have about clean code and how they use it in practice. There is not much information about how clean code is perceived by developers and applied in practice, and this thesis will extend the information about those two areas. It is an effort to understand developers' perception of clean code in practice and what they think about it. Realization (Method). To understand the state-of-the-art in the area of clean code, we first performed  literature review using snowballing. To delve into developers' perception about clean code and how it is used in practice. We have developed and sent out a questionnaire survey to developers within companies and shared the survey via social networks. We ask if developers believe that clean code eases the process of reading, modifying, reusing, or maintaining code. We also investigate whether developers write clean code initially or refactor it to become clean code, or do none of these. Finally, we ask developers in practice what clean code principles they agree or disagree with. Asking this will help identify which clean code principles developers think are helpful and which are not. Results. The results from the investigation are that the developers strongly believe in clean code and that it affects reading, modifying, reusing, and maintaining code, positively. Also, developers do not write clean code initially but rather refactor unclean code to become clean code. Only a small portion of developers write clean code initially, and some do what suits the situation, while some do neither of these. The last result is that developers agree with most of the clean code principles listed in the questionnaire survey and that there are also some principles that they discard, but these fewer. Conclusions. From the first research question, we know that developers strongly believe that clean code makes the code more readable, understandable, modifiable, or reusable. Also, developers check that the code is readable using code reviews, peer reviews, or pull requests. Regarding the second research question, we know that developers mostly refactor unclean code rather than write clean code initially. The challenges are that to write clean code initially, a developer must have a solid understanding of the problem and obstacles in advance, and a developer will not always know what the code should look like in advance. The last research question showed that most developers agree with most of the clean code principles and that only a small portion of developers disagree with some of them. Static code analysis and code quality gates can ensure that developers follow these clean code practices and principles.

Stora och komplexa kodbaser med bristfällig kodförståelse är ett problem som blir allt vanligare bland företag idag. Bristfällig kodförståelse resulterar i längre tidsåtgång vid underhåll och modifiering av koden, vilket för ett företag leder till ökade kostnader. Clean Code anses enligt somliga vara lösningen på detta problem. Clean Code är en samling riktlinjer och principer för hur man skriver kod som är enkel att förstå och underhålla. Ett kunskapsglapp identifierades vad gäller empirisk data som undersöker Clean Codes påverkan på kodförståelse. Studiens frågeställning var: Hur påverkas förståelsen vid modifiering av kod som är refaktoriserad enligt Clean Code principerna för namngivning och att skriva funktioner? För att undersöka hur Clean Code påverkar kodförståelsen utfördes ett fältexperiment tillsammans med företaget CGM Lab Scandinavia i Borlänge, där data om tidsåtgång och upplevd förståelse hos testdeltagare samlades in och analyserades. Studiens resultat visar ingen tydlig förbättring eller försämring av kodförståelsen då endast den upplevda kodförståelsen verkar påverkas. Alla testdeltagare föredrar Clean Code framför Dirty Code även om tidsåtgången inte påverkas. Detta leder fram till slutsatsen att Clean Codes effekter kanske inte är omedelbara då utvecklare inte hunnit anpassa sig till Clean Code, och därför inte kan utnyttja det till fullo. Studien ger en fingervisning om Clean Codes potential att förbättra kodförståelsen. / Summary: Big and complex codebases with inadequate understandability, is a problem which is becoming more common among companies today. Inadequate understandability leads to bigger time requirements when maintaining code, which means increased costs for a company. Clean Code is according to some people the solution to this problem. Clean Code is a collection of guidelines and principles for how to write code which is easy to understand and maintain. A gap of knowledge was identified, as there is little empirical data that investigates how Clean Code affects understandability. This lead to the following the question: How is the understandability affected when modifying source code which has been refactored according to the Clean Code principles regarding names and functions? In order to investigate how Clean Code affects understandability, a field experiment was conducted in collaboration with the company CGM Lab Scandinavia in Borlänge. In the field experiment data in the form of time and experienced understandability was collected and analyzed.The result of this study doesn’t show any clear signs of immediate improvements or worsening when it comes to understandability. This is because even though all participants prefer Clean Code, this doesn’t show in the measured time of the experiment. This leads me to the conclusion that the effects of Clean Code aren’t immediate, since developers hasn’t been able to adapt to Clean Code, and therefore are not able to utilize its benefits properly. This study gives a hint of the potential Clean Code has to improve understandability

Idag byggs många system som består av svårlästa kodbaser med låg förvaltningsbarhet. En anledning till detta är att utvecklarna av systemet har olika bakgrund och kunskap i hur de skriver kod. Att skriva sin kod på helt skilda sätt är något som kan skapa problem i takt med att system blir större och allt mer komplexa. Nethouse i Borlänge har sedan 2015 arbetat med förvaltningsuppdraget TRAP (Transportstyrelsens Administrativa Processystem) där en problematiskt förvaltning upplevts i och med att systemet är uppbyggt med hjälp av olika tekniker. Tekniken i TRAP ska lyftas och målet med detta är att skapa en mer lättläst och förvaltningsbar kodbas jämfört med hur TRAP ser ut idag. För att uppnå detta är planen att i teamet etablera ett gemensamt tankesätt som grundas i de riktlinjer som Clean code förespråkar. Studien syftar till att beskriva hur ett team arbetar med etableringen av ett gemensamt tankesätt som grundas i Clean Codes riktlinjer samt faktorer som anses vara viktiga att beakta. För att uppnå syftet användes två frågeställningar:  Hur arbetar teamet med etableringen av det gemensamma tankesättet idag?  Vilka faktorer kan anses som viktiga att beakta när ett nytt gemensamt tankesätt ska etableras? En fallstudie utfördes med intervjuer och enkäter som datainsamlingsmetoder för att ha möjlighet att besvara frågeställningen. Resultatet från studien visar att teamet på Nethouse använder sig av par- och mobprogrammering samt i enstaka fall kodgranskning för att etablera det gemensamma tankesättet. Resultatet beskriver även fyra faktorer som är viktiga att beakta när ett gemensamt tankesätt som grundas i Clean codes riktlinjer ska etableras. De fyra faktorerna är ömsesidigt förtroende, ömsesidighet kring det arbete som utförs, tvåvägskommunikation och tillvägagångssätt. / Many of todays systems are made of code bases with low readability which leads to low maintainability. One reason to this is that developers of the system have different experience and knowledge in how to write code. When code is written in totally different ways it can create problems as the system grows and becomes more complex. Since 2015, Nethouse in Borlänge has managed a system called TRAP (Transportstyrelsens Administrative Process System). TRAP is built with different techniques and during the maintainability process a lot of problems has occured because of that. The technique in TRAP is about to be lifted and by doing this one part of the goal is to create a code base which is more easy to read and maintain compared to todays code base. To achieve this goal the plan is to establish a common mindset in the team. A common mindset which is based in a set of guidelines called Clean code. The purpose of this study is to describe how a team is working to establish a common mindset based in the guidelines of Clean code and to describe important factors to consider in this situation. Two research questions was used to achieve the purpose of this study:  How is the team working today to establish a common mindset?  Which factors can be considered as important when a common mindset is about to establish? A case study with the help of interviews and questionnaries was conducted to answer these two questions. The result shows that the team is using pair programming, mob programming and also code review to establish a common mindset. The result also shows that the four factors mutual trust, mutual performance monitoring, closed loop communication and method are more important to consider in this situation.

The goal of this thesis is to design and implement coding conventions management system for project. Prior to the creation of the system itself, the research of coding conventions benefits, the analysis of used technologies in open source projects at GitHub service, and the analysis of existing technologies managing coding conventions was done. On the basis of that, usage scenarios were designed, requirements were specified and system architecture was determined. Then the system was implemented as web application based on Blazor and EditorConfig technologies. The main aim was to create a system that would allow to store all types of programming conventions and at the same time allows users to automatically control and generate them. It is published under an open source license within the GitHub service and deployed on the Azure cloud platform.

Denna kandidatrapport beskriver det arbete som utfördes i kursen TDDD96, Kandidatprojekt i programvaruutveckling, våren 2024 vid Linköpings universitet. Arbetet gick ut på att vidareutveckla mjukvaruprojektet Arch. Arch är en webbapplikation ämnad att hjälpa privatpersoner digitalt rita upp hus. Detta för att utforska möjligheter kring nybygge eller ombyggnation samt producera fackmannamässiga ritningar som kan bifogas i bygglovsansökan. Rapporten behandlar hur värde kan skapas för kunden med avseende på mjukvaruprojektet Arch, samt vilka erfarenheter som kan dokumenteras därifrån. Ytterligare utforskar rapporten fördelar och nackdelar med att skapa och följa upp en systemanatomi, följa Clean Code-principer samt att ärva en befintlig kodbas. Rapporten inleds med en introduktion och bakgrund, följt av nödvändig teori. Därefter beskrivs den metod som använts för att utföra projektarbetet och samla erfarenheter. I rapporten redovisas ett flertal slutsatser. Det kan vara svårt att veta hur man ska vidareutveckla ett system för att skapa värde för kunden, annat än att kontrollera med kundens representanter huruvida de upplever att arbetet har ett värde för dem. Det är också av yttersta vikt att inledningsvis noggrant planera och strukturera utvecklingsprocessen, samt dokumentera koden för att underlätta överlämning och övertagande av den. Vidare upplevde projektgruppen att en systemanatomi kan ge ett visst stöd i det initiala skapandet av användarscenarion. Utöver detta upplevdes det som att systemanatomin hade mycket begränsade användningsområden för projektgruppen. Ytterligare fanns det upplevda fördelar med att använda Clean Code-principerna vid webbutveckling, dock ansågs det inte helt lämpligt att använda för den syntax som uppkommer inom webbutveckling. Avslutningsvis fanns det en del upplevda utmaningar med att ärva en kodbas med hög komplexitet och avsaknad av övergripande dokumentation.

Every second, there are many attempts to attack various entities on the Internet. This is why high-quality, fast, and up-to-date tools are needed to easily analyze network traffic. Netfox Detective is one of such tools. Specifically, it is used for forensic analysis of network communication. The aim of this work is to migrate Netfox Detective to the newest version of .NET platform (.NET 5), including refactoring with respect to user experience and correct use of software design patterns. This thesis deals not only with the migration itself, but is listing common mistakes programmers make along with possible solutions to these mistakes. The chapters contain a detailed decision log that can help guide other developers to better solutions. Furthermore, the work deals with analysis and creation of unit tests and with correct use of tools for CI/CD. Fully migrated project is not the only output of this thesis. A development environment for the project has been prepared in GitLab and it is ready to be used.

Denna rapport har sitt ursprung i det kodefaktoriseringsarbete som utfärdats våren 2013 som examensarbete i dataingenjörsprogrammet vid Örebro Universitet. Arbetet utfärdades på Nethouse i Örebro, och hade stort fokus på koddesign och kodkvalitet. I rapporten diskuteras vilka faktorer som påverkar hur underhållbar och läsbar en kod är, men också hur man på ett rimligt sätt kan utvärdera och mäta kodkvalitet. Den teoretiska biten blandas med den praktiska, där läsaren introduceras för ett flertal metoder, och hur dessa sedan implementerades i det faktiska projektet som Nethouse tillhandahöll. / This report has its origins in the code refactoring work issued in spring 2013 as a Degree Project in the Computer Engineering Programme, at Örebro University. The work took place at Nethouse in Örebro, and had a major focus on code design, and code quality. The report discusses the factors that affect how maintainable and readable a code is, but also how to reasonably evaluate and measure code quality. The theory is mixed with the practical, where the reader is introduced to a variety of methods, and how these were then implemented in the actual project that Nethouse provided.

Refactoring wird angewandt, wenn eine Software-Inspektion Defekte im Programmcode feststellt. Code-Smells sind Beispiele solcher Defekte im Programmcode. Clean-Code ist ein neuerer Ansatz, der genauso wie das Code-Smell-Konzept festlegt, wann Defekte im Programmcode vorliegen. Für Code-Smells gibt es bereits zahlreiche Code-Analyse-Tools, die die automatische Erkennung solcher Defekte ermöglicht. Die vorliegende Arbeit implementiert ein Clean-Code-Analyse-Tool für Programmcode mithilfe von statischer Code-Analyse, das Refactoring-Hinweise ausgibt. Für diesen Zweck werden ein Lexer und ein Parser zur syntaktischen Analyse eines Subsets der Programmiersprache C++ implementiert. Die Evaluation durch quantitative Datenanalyse zeigt, wie nützlich die automatische Erkennung von Clean-Code mithilfe eines statischen Code-Analyse-Tools bei der Erstellung von Programmcode mit höherer Lesbarkeit für Entwicklerinnen und Entwickler ist.:Inhaltsverzeichnis 6 Abbildungsverzeichnis 9 Tabellenverzeichnis 10 Akronyme 13 1. Einleitung 14 2. Theoretische Grundlagen 17 2.1. Wichtige Begriffe und Definitionen 17 2.1.1. Software-Inspektion 17 2.1.2. Fagan-Inspektion 18 2.1.3. Checklistenbasiertes Code-Review 19 2.1.4. Statische vs. dynamische Code-Analyse-Tools 21 2.1.5. Refactoring 24 2.1.6. Code-Smells 24 2.1.7. Clean-Code 25 2.2. Code-Smell-Heuristiken im Detail 27 2.3. Einführung in den Compilerbau 32 2.3.1. Kurze Einführung in die Sprachtheorie 32 2.3.2. Die lexikalische Analyse 34 2.3.3. Die syntaktische Analyse 35 3. Forschungsstand 38 3.1. Code-Smell-Analyse-Tools auf Grundlage von Strukturinformationen 42 3.2. Code-Smell-Analyse durch maschinelles Lernen 50 3.3. Code-Smell-Suche mithilfe von Änderungsdaten 52 3.4. Code-Smell-Erkennung durch Textanalyse 54 4. Forschungsfragen und Konzeptentwicklung 56 4.1. Clean-Code: Welche Teile sind messbar? - Die Konzeptionalisierung hin zu einem maschinenlesbaren Ansatz 56 4.1.1. Größe von Entitäten im Clean-Code 57 4.1.2. Clean-Code und Zugriffsmodifikatoren 59 4.1.3. Bezeichner von Entitäten im Clean-Code 60 4.1.4. Formatierungskonventionen des Clean-Codes 62 4.1.5. Funktionsparameterübergabe im Clean-Code-Konzept 63 4.1.6. Clean-Code-Kommentare 65 4.1.7. Clean-Code — Was nicht geht 66 4.1.8. Platzierung von Entitäten im Clean-Code 67 4.2. Forschungsfragen und Hypothesen 69 5. Methodik 71 5.1. Implementierung des statischen Clean-Code-Analyse-Tools 71 5.1.1. Abhängigkeiten 72 5.1.2. Umsetzung des statischen Clean-Code-Analyse-Tools 72 5.1.3. Abhängige Variablen 78 5.2. Checklistenbasiertes Code-Review 80 5.2.1. Begründung der Methodenauswahl 80 5.2.2. Fragebogen 81 5.2.3. Unabhängige Variablen 85 5.2.4. Ablauf der Studie 86 6. Ergebnisse 87 6.1. Populationsbeschreibung 88 6.2. Deskriptive Werte der Evaluationsitems aus der Lesbarkeitsstudie 88 6.3. Deskriptive Werte der Evaluation des statischen Clean-Code-Analyse-Tools 90 6.4. Inferenzstatistik 91 7. Diskussion 96 7.1. Beantwortung der Forschungsfrage 96 7.2. Bedrohungen der Validität 97 7.3. Ausblick und Vergleich mit ähnlichen Code-Analyse-Tools 98 8. Fazit 100 Literaturverzeichnis 102 A. Anhang 112 A.1. Tabellen 112 A.2. Clean-Code Analyse-Tool Ein- und Ausgabe 124 A.3. Lesbarkeitsstudie 135 A.4. Regressionsergebnisse 144 B. CD 148 C. Selbstständigkeitserklärung 148

Studiens syfte är att bedöma till vilken utsträckning AI kan ersätta en människa i rollen som mjukvaruutvecklare utifrån ett kvalitativt perspektiv på kod. Detta görs genom att besvara forskningsfrågorna som lyder: “Hur använder mjukvaruutvecklare sig av generativ AI vid utvecklingsutmaningar?” och “Vad är mjukvaruutvecklares uppfattning om kvaliteten på autogenererad kod skapad av en generativ AI såsom Chat GPT?”. För att besvara frågorna har en kvalitativ metod applicerats. En litteraturundersökning startade studien och tillsammans med en ny modell som baseras på McCall quality model och Boehm quality model. Från detta har en intervjuguide skapats som används i semistrukturerade intervjuer genomförda med erfarna mjukvaruutvecklare. Resultatet visar att kod skapad av generativ AI är ett bra hjälpmedel och verktyg som kan effektivisera en mjukvaruutvecklare och att det används på det sättet idag. Däremot så visar resultaten också att koden som genereras av en generativ AI inte är tillräckligt bra och kan inte användas utan att förändringar eller åtgärder görs då det saknas kvalitet. Slutsatserna som dras är att mjukvaruutvecklare använder sig av generativ AI som ett hjälpmedel men att AI:n inte är kapabel att hantera en uppgift på egen hand, därav är det inget hot mot någon anställning för mjukvaruutvecklare. Framtida forskning bör göras på autogenererad kod. Fler verktyg bör undersökas för att utvidga kunskapen om dess kapacitet samt bör det undersökas vilken inverkan generativ AI kan ha på andra branscher. / The aim of this study, conducted and written in Swedish, is to assess the potential of replacing a human software developer with generative AI. The study evaluates the quality of code generated by a generative AI model, this is done by answering the following research questions: “How do software developers use generative AI for development challenges'' and “How do software developers perceive the quality of code autogenerated by a generative AI such as Chat GPT”. To answer the questions we employ a qualitative research method. The study began with a literature review and based our evaluation of software quality on a hybrid model that modifies and combines McCall quality model and Boehm software quality model. The literature review and the hybrid model was used as a base to shape an interview guide. The interview guide was used in semistructured interviews conducted with experienced software developers. The results suggest that autogenerated code from generative AI is a viable aid for software developers as it makes them more effective in a number of tasks. However, the results also show that the autogenerated AI code has insufficient quality as a complete solution, and therefore often requires further fine-tuning and improvements from software developers. From the results, we conclude that software developers do use generative AI as a tool while writing code. Generative AI enhances software developers effectiveness but the current state of generative AI cannot fully replace a human software developer hence it is not a threat to any employment. Future research should be conducted on auto generated code. Some more tools should be studied to broaden the knowledge on its capabilities as well as looking at the implications that generative AI have on other industries.