Object-oriented languages have made a shift towards incorporating functional concepts such as lambdas. Lambdas are anonymous functions that can be used within the scope of other functions. In C++ lambdas are considered difficult to use for inexperienced developers. This implies that there may be problems with lambdas in C++. However, studies about lambdas in C++ repositories are scarce, compared to other object-oriented languages such as Java. This study aims to address a knowledge gap regarding how lambdas are used by developers in C++ repositories. Furthermore, examine how developer experience and software engineering practices, such as unit testing and in-code documentation, correlates with the inclusion of lambdas. To achieve this we create a set of tools that statically analyse repositories to gather results. This study gained insight into the number of repositories utilising lambdas, their usage areas, and documentation but also how these findings compare to similar studies’ results in Java. Further, it is shown that unit testing and developer experience correlates with the usage of lambdas. / Objektorienterade språk har gjort en förskjutning mot att integrera funktionella begrepp som lambdas. Lambdas är anonyma funktioner som kan användas inom ramen för andra funktioner. I C ++ anses lambdas vara svåra att använda för oerfarna utvecklare. Detta innebär att det kan vara problem med lambdas i C ++. Emellertid är studier på lambdas i C ++ repositorier mindre vanliga jämfört med andra objektorienterade språk som Java. Denna studie syftar till att ta itu med ett kunskapsgap beträffande hur lambdas används av utvecklare i C++ repositorier. Dessutom undersöks hur utvecklarvanor och sedvänjor i programvaruutveckling, till exempel enhetstestning och dokumentation, korrelerar med inkluderingen av lambdas. För att uppnå detta skapar vi en uppsättning verktyg som statiskt analyserar repositorier för att samla resultat. Denna studie fick inblick i antalet repositorier som använder lambdas, deras användningsområden och dokumentation men också hur dessa resultat jämför sig med liknande studieresultat i Java. Vidare har det visats att enhetstestning och utvecklaren erfarenhet korrelerar med användningen av lambdas.

Security deficiencies that occur in web applications can have major consequences. PHP is a language that is often used for web applications and it places high demands on how the language is used to ensure it is safe. There are several features in PHP that should be handled with care to avoid security flaws. Static code analysis can help find vulnerabilities in code, but there are some drawbacks that can occur with static code analysis tools. One disadvantage is false positives which means that the tool reports vulnerabilities that do not exist. There are also false negatives which means the tool cannot find the vulnerability at all which can lead to a false sense of security for the user of the tool. With the help of completed test cases, three tools have been investigated in a case study to find out if the tools differ in their ability to avoid false positives and false negatives. The study also examines whether the tools' rules consider the PHP language's vulnerable functions. To answer the research question, a document collection was conducted to obtain information about the tools and various vulnerabilities. The purpose of this study is to compare the ability of static code analysis tools to find PHP code vulnerabilities. The tools that were investigated were SonarQube, Visual Code Grepper (VCG) and Exakat. The study's analysis shows that VCG found the most vulnerabilities but failed to avoid false positive vulnerabilities. Exakat had zero false positives but could not avoid false negatives to the same extent as VCG. SonarQube avoided all false positives but did not find any of the vulnerabilities tested in the test cases. According to the rules of the tools, VCG had more consideration for the risky functions found in PHP. The study's results show that the tools' ability to avoid false positives and false negatives differed and their adaptation to the PHP language's vulnerable functions. / Säkerhetsbrister som förekommer i webbapplikationer kan leda till stora konsekvenser. PHP är ett språk som ofta används för webbapplikationer och det ställer höga krav på hur språket används för att det ska vara säkert. Det finns flera funktioner i PHP som bör hanteras varsamt för att inte säkerhetsbrister ska uppstå. Statisk kodanalys kan hjälpa till med att hitta sårbarheter i kod men det finns vissa nackdelar som kan uppkomma med statiska kodanalysverktyg. En nackdel är falska positiva vilket betyder att verktyget rapporterar in sårbarheter som inte finns. Det finns också falska negativa som betyder att verktyget inte hittar sårbarheten alls vilket kan leda till en falsk trygghetskänsla för användaren av verktyget. Med hjälp av färdiga testfall så har tre verktyg utretts i en fallstudie för att ta reda på om verktygen skiljer sig i sin förmåga till att undvika falska positiva och falska negativa. Studien undersöker också om verktygens regler tar PHP-språkets sårbara funktioner i beaktning. För att kunna besvara forskningsfrågan har en dokumentsinsamling genomförts för att få information om verktygen och olika sårbarheter. Studiens syfte är att jämföra statiska kodanalysverktygs förmåga att hitta sårbarheter i PHP-kod. De verktyg som utreddes var SonarQube, Visual Code Grepper (VCG) och Exakat. Studiens analys visar att VCG hittade mest sårbarheter men lyckades inte undvika falska positiva sårbarheter. Exakat hade noll falska positiva men kunde inte undvika falska negativa i lika stor utsträckning som VCG. SonarQube undvek alla falska positiva men hittade inte någon av de sårbarheter som testades i testfallen. Enligt verktygens regler visade sig VCG ta mest hänsyn till de riskfyllda funktioner som finns i PHP. Studiens resultat visar att verktygens förmåga att undvika falska positiva och falska negativa och deras anpassning för PHP språkets sårbara funktioner skiljde sig åt.

In the aviation industry, the use of software development tools is not as easily adopted as in other industries. Due to the catastrophic consequences of software errors in airborne systems, software development processes has rigorous requirements. One of these requirements is that a code standard must be followed. Code standards are used to exclude code constructions which could result in unwanted behaviours. The process of manually ensuring a specific code standard can be costly. This process could be automated by a tool for static code analysis, however, this requires a formal qualification. This thesis evaluates the process of qualifying a tool for static code analysis in accordance with the requirements of the major aviation authorities EASA and FAA. To describe the qualification process, a literature study was conducted. To further explain how an existing tool could be put through the qualification process, a case study of the existing tool Parasoft C/C++ test was conducted. The results of the literature study show what processes must be completed in order to qualify a static code analysis tool. Importantly, the study shows that no requirements are put on the development process of the tool. This was an important takeaway as it meant that an existing tool could be qualified without any additional data from the developer of the tool. The case study of Parasoft C/C++ test showed how the tool could be configured and verified to analyze code in accordance with a small set of code rules. Furthermore, three documents including qualification data were produced showing how the qualification process should be documented in order to communicate the process to an authority. The results of the thesis do not provide the full picture of how a tool could be qualified as the software, in which the tool is used, is considerations the are specific to the software the tool is used to develop still need to be taken into consideration. The thesis does, however, provide guidance on the majority of the applicable requirements. Future research could be done to provide the complete picture of the qualification process, as well as how the process would look like for other types of tools. / Inom flygindustrin är användandet av olika programmeringsverktyg inte lika självklart som inom andra industrier. På grund av de katastrofala konsekvenser som fel i mjukvaran i ett flygplan kan resultera i finns det rigorösa krav på mjukvaruutvecklingsprocessen. Ett av dessa krav är att en viss kodstandard måste upprätthållas. Kodstandarder används för att exkludera vissa strukturer i kod som kan leda till oönskat beteende. Upprätthållandet av en viss kodstandard är en långdragen process att genomföra manuellt, och kan därför automatiseras med hjälp av ett statiskt kodanalysverktyg. För att kunna använda ett sådant verktyg behövs däremot en formell verktygskvalificering. I denna uppsats kommer kvalificeringsprocessen av ett verktyg för statisk kodanalys att evalueras enligt de krav som de två stora flygmyndigheterna EASA och FAA ställer. För att förklara processen av att kvalificera ett sådant verktyg gjordes en litteraturstudie följt av en fallstudie av det existerande verktyget Parasoft C/C++ test. Resultaten av litteraturstudien beskriver de olika processerna som måste genomföras för att kvalificera ett statiskt kodanalysverktyg. Noterbart är att resultaten visar att inga krav ställs på utvecklingsprocessen av verktyget själv. Detta betyder att ett existerande kommersiellt verktyg kan kvalificeras utan att verktygsutvecklarna själva behöver bidra med extra information. Fallstudien visade hur verktyget Parasoft C/C++ test kan konfigureras och verifieras att följa en viss kodstandard. Vidare resulterade fallstudien i utkast av de nödvändiga dokumenten som behöver produceras för att kommunicera kvalificeringsprocessen till en myndighet. De resultat som presenteras i denna uppsats är i sig inte tillräckliga för beskriva hela kvalificeringsprocessen. Ytterligare överväganden som är specifika till den mjukvaran som verktyget ska användas till att utveckla måste göras för att en komplett kvalificering ska kunna genomföras. Uppsatsen bidrar däremot med riktlinjer och vägledning av majoriteten av de processerna som behöver genomföras. Ytterligare forskning kan göras för att bidra med den kompletta bilden av verktygskvalificering av ett statiskt kodanalysverktyg, samt hur kvalificering kan göras av andra typer av verktyg.

Establishing and preserving a high level of software quality is a not a trivial task, although the benefits of succeeding with this task has been proven profitable and advantageous. An approach to mitigate the decreasing quality of a project is to track metrics and certain properties of the project, in order to view the progression of the project’s properties. This approach may be carried out by introducing continuous code inspection with the application of static code analysis. However, as the initial common opinion is that these type of tools produce a too high number of false positives, there is a need to investigate what the actual case is. This is the origin for the investigation and case study performed in this paper. The case study is performed at Ida Infront AB in Linköping, Sweden and involves interviews with developers to determine the performance of the continuous inspection platform SonarQube, in addition to examine the general opinion among developers at the company. The author executes the implementation and configuration of a continuous inspection environment to analyze a partition of the company’s product and determine what rules that are appropriate to apply in the company’s context. The results from the investigation indicate the high quality and accuracy of the tool, in addition to the advantageous functionality of continuously monitoring the code to observe trends and the progression of metrics such as cyclomatic complexity and duplicated code, with the goal of preventing the constant increase of complex and duplicated code. Combining this with features such as false positive suppression, instant analysis feedback in pull requests and the possibility to break the build given specified conditions, suggests that the implemented environment is a way to mitigate software quality difficulties. / 建立和保持高水平的软件质量可以带来经济利益等诸多好处，然而这是一项很困难的任务。其中一种防止软件项目质量下降的方法是通过跟踪项目的度量值和某些属性，来查看项目的属性的变化情况。通过引入持续的代码审查和应用静态代码分析方法可以实现这种方法。然而，在人们的印象中，这类工具往往具有较高的误检，因此需要进一步调查实际情况、研究其可行性，这是本文的初始研究目标。本文在瑞典林雪平的Ida Infront AB公司开展了案例研究，调研了该公司开发人员的意见，并通过访问开发人员，确定持续的代码审查平台SonarQube的性能。作者对持续的代码审查环境进行了配置，分析了公司的部分产品，进而确定哪些规则适用于该公司。调查结果表明该工具是高质量并且准确的，还提供了持续监测代码来观察度量值的趋势和进展等先进功能，例如通过监测环路复杂度和重复代码等度量值，来防止复杂度和重复代码的增加。通过组合误检压缩、对pull requests的瞬间分析反馈、以及分解和建立给定的条件等特征，使得所实现的环境成为一种可以降低软件质量保障难度的方式。

Aim Develop an IT artifact that provides formative feedback for students based on their programming assignments. Background One of the best methods to learn programming is by practice. Providing feedback to students is an important and a valuable factor for improving learning, which plays a vital part in the student’s possibility to enhance and improve its solutions. Software development courses have several assignments and each course instructs about 100 students. To assess and provide feedback for all the students and each assignment demands considerable resources. In a survey conducted by TCO (2013) half of the respondents’ state that feedback is rarely or never given in reasonable time. Method Action Design Research (ADR) was used to intervene an organizational problem in parallel with building and evaluating an IT artifact. Conclusion The results from the study were four generated design principles and a proposed solution on how to use existing static code analysis tools for provide formative feedback to students.