[pt] Sistemas de software provavelmente enfrentarão os chamados problemas de projeto. Um problema de projeto é o resultado de más decisões que podem afetar alguns atributos de qualidade importantes do sistema de software, como manutenção, desempenho e afins. Dada a típica falta de documentação do projeto, os desenvolvedores precisam confiar em sintomas que aparecem a nível de implementação para identificar e remover problemas de projeto. Um sintoma a nível de implementação geralmente se manifesta como uma anomalia de código, que se trata de uma microestrutura no programa possivelmente indicando a presença de (ou parte de) um problema de projeto. Grandes programas possuem centenas ou milhares de elementos (pacotes, classes, interfaces e afins) nos quais uma proporção significativa é afetada por anomalias. No entanto, muitas dessas anomalias não possuem relação com problemas de projeto, em outras palavras, elas não são anomalias relevantes ao problema de projeto. Desse modo, torna-se difícil e demorado priorizar os elementos anômalos do programa que são suspeitos de terem problema de projeto. Infelizmente, a literatura não fornece aos desenvolvedores heurísticas que auxiliem a priorização destes elementos de projeto suspeitos. Neste contexto, esta dissertação reporta dois estudos que objetivam auxiliar na elaboração de tais heurísticas, visando auxiliar o desenvolvedor nas decisões de priorização. O objetivo destas heurísticas é localizar uma pequena lista de elementos suspeitos de terem anomalias de código relevantes ao problema de projeto. Nosso primeiro estudo consiste em uma análise qualitativa para determinar os critérios utilizados pelos desenvolvedores para a priorização de elementos suspeitos de terem problemas de projeto. Com base nesses critérios, derivamos um conjunto preliminar de heurísticas de priorização. Nosso segundo estudo centrou-se na avaliação destas heurísticas. Como resultado, descobrimos que duas das nove heurísticas alcançaram os melhores resultados de precisão. As melhores heurísticas são baseadas em dois critérios: diversidade de anomalias e granularidade das anomalias. Nossas descobertas sugerem que fomos capazes de obter uma primeira abordagem promissora para apoiar os desenvolvedores na priorização de elementos com anomalias de código relevantes ao projeto de software. / [en] Software systems are likely to face what is called design problems. A design problem is the result of bad decisions that can aect some important quality attributes of the software system such as maintainability, performance and the like. Given the typical lack of design documentation, developers have to rely on implementation-level symptoms to identify and remove design problems. An implementation-level symptom usually manifests as a code smell, a micro-structure in the program possibly indicating the presence of (or part of) a design problem. Large programs have hundreds or thousands of program elements (packages, classes, interfaces, and the like) in which a significant proportion is aected by smells. However, many of these smells may bear no relationship with design problems, i.e. they are not design-relevant smells. Then, it becomes hard and time-consuming to prioritize smelly program elements being suspects of having a design problem. Unfortunately, the literature fails to provide developers with heuristics to support the prioritization of these suspicious program elements. In this context, this dissertation reports two studies aimed at assisting in the elaboration of such prioritization heuristics. The goal of these heuristics is to locate a short (high priority) list of smelly program elements, which are suspects of having design-relevant smells. Our first study consists of a qualitative analysis on recurring criteria used by developers, in practice, to prioritize elements suspicious of having design problems. Based on these criteria, we derived a preliminary suite of prioritization heuristics. Our second study focused on the evaluation of the proposed heuristics. As a result, we found that two out of nine heuristics reached the best results in precision. The best heuristics are based on two criteria: smell diversity and smell granularity. Our findings suggest that we were able to derive a first promising approach to support developers in prioritizing elements with design-relevant smells.

Much of software engineering research and practice is concerned with improving software quality. While enormous prior efforts have focused on improving the quality of programs, this dissertation instead provides the means to educate the next generation of programmers who care deeply about software quality. If they embrace the culture of quality, these programmers would be positioned to drastically improve the quality of the software ecosystem. This dissertation describes novel methodologies, techniques, and tools for introducing novice programmers to software quality and its systematic improvement. This research builds on the success of Scratch, a popular novice-oriented block-based programming language, to support the learning of code quality and its improvement. This dissertation improves the understanding of quality problems of novice programmers, creates analysis and quality improvement technologies, and develops instructional approaches for teaching quality improvement. The contributions of this dissertation are as follows. (1) We identify twelve code smells endemic to Scratch, show their prevalence in a large representative codebase, and demonstrate how they hinder project reuse and communal learning. (2) We introduce four new refactorings for Scratch, develop an infrastructure to support them in the Scratch programming environment, and evaluate their effectiveness for the target audience. (3) We study the impact of introducing code quality concepts alongside the fundamentals of programming with and without automated refactoring support. Our findings confirm that it is not only feasible but also advantageous to promote the culture of quality from the ground up. The contributions of this dissertation can benefit both novice programmers and introductory computing educators. / Doctor of Philosophy / Software remains one of the most defect-prone artifacts across all engineering disciplines. Much of software engineering research and practice is concerned with improving software quality. While enormous prior efforts have focused on improving the quality of programs, this dissertation instead provides the means to educate the next generation of programmers who care deeply about software quality. If they embrace the culture of quality, these programmers would be positioned to drastically improve the quality of the software ecosystem, akin to professionals in traditional engineering disciplines. This dissertation describes novel methodologies, techniques, and tools for introducing novice programmers to software quality and its systematic improvement. This research builds on the success of Scratch, a popular visual programming language for teaching introductory students, to support the learning of code quality and its improvement. This dissertation improves the understanding of quality problems of novice programmers, creates analysis and quality improvement technologies, and develops instructional approaches for teaching quality improvement. This dissertation contributes (1) a large-scale study of recurring quality problems in Scratch projects and how these problems hinder communal learning, (2) four new refactorings, quality improving behavior-preserving program transformations, as well as their implementation and evaluation, (3) a study of the impact of introducing code quality concepts alongside the fundamentals of programming with and without automated refactoring support. Our findings confirm that it is not only feasible but also advantageous to promote the culture of quality from the ground up. The contributions of this dissertation can benefit both novice programmers and introductory computing educators.

Motion controlled games can be a good physical activity for children, but the game has to be fun and engaging. We have, with a starting point in an existing base game, developed an achievement module which follows certain code standards to make it easier to understand, and to make hand overs of the code smoother. More work on the rest of the game has also been done to make it more engaging, while clean up of the existing code to follow the same standards.

Software development can be a difficult and time consuming task. In addition, producing good code is even more difficult. Poor design and implementation choices in software code can result in an end product that is both difficult to understand and difficult to maintain. A collective name for implementation and design choices that is considered to have a negative impact or indicate something negative in software code is Code smells. In this study, we identify 34 unique code smells through a systematic literature study. The results are then ranked and validated with interviews with people who work or have worked with Javascript in a professional environment at some point during the past five years. The end result is a ranked list of 32 code smells that are applicable to Javascript. The result shows that the five highest ranked code smells are Variable name conflict in closures, Depth, Argument Type Mismatch, Duplicated code and Excessive global Variables.

[pt] O projeto de software resulta das decisões ao longo do seu desenvolvimento. Algumas dessas decisões podem levar a problemas de projeto, afetando negativamente os requisitos não funcionais (RNFs). Embora seja crucial identificar esses problemas, essa é uma tarefa complexa, especialmente quando o código-fonte é o único artefato disponível. Nessa tarefa, os desenvolvedores podem ter que considerar vários sintomas (por exemplo, anomalias de código) para identificar até mesmo um único problema de projeto. Estudos anteriores sugerem que usar um único sintoma pode ser inadequado para identificar tais problemas. Portanto, nesta tese, investigamos como múltiplos sintomas podem ser usados nessa identificação. Em nosso primeiro estudo, nos concentramos em investigar o uso de anomalias de código bem conhecidos (anomalias de manutenabilidade). Nós identificamos que os desenvolvedores podem se beneficiar desse tipo de sintoma quando as ocorrências das anomalias afetam a mesma localização do programa e formam um padrão, podendo indicar melhor a presença de um problema de projeto. No entanto, também revelamos as limitações ao depender exclusivamente desse tipo de sintoma, destacando a necessidade de contexto adicional. Isso nos levou ao segundo estudo, onde investigamos um tipo adicional de sintoma, anomalias de robustez, e seu uso combinado com anumalias de manutenabilidade. Nós identificamos que ambos os tipos de anomalia de código podem ajudar os desenvolvedores na identificação de problemas de projeto principalmente relacionados à má modularização do sistema. Através desses dois estudos, observamos a necessidade de compreender as perspectivas e estratégias dos desenvolvedores em relação aos RNFs do sistema. Ao fazê-lo, podemos potencialmente entender quem são os desenvolvedores mais capazes de prevenir, discutir e identificar problemas de projeto. Isso nos levou ao terceiro estudo, onde investigamos como os desenvolvedores discutem e abordam RNFs em seus sistemas, revelando estratégias comuns em relação a esses requisitos. Esses resultados nos proporcionaram uma compreensão mais abrangente de como os desenvolvedores podem combinar diferentes sintomas e como percebem sua importância dentro de seus sistemas. / [en] Software design results from stakeholder decisions made through software development. Some of these decisions may lead to design problems, negatively impacting non-functional requirements (NFRs). Even though identifying design problems is crucial, this is a complex task, especially when the source code is the only artifact available. Along this task, developers may have to reason about multiple symptoms (e.g., code smells and nonconformities with NFRs) to identify even a single design problem. In fact, previous studies suggest that relying on a single symptom may be inadequate for the design problem identification. Thus, in this thesis, we investigate the role that the use of multiple symptoms may have on the identification of design problems. In our first study, we focused on investigating the use of well-known code smells (called here maintainability smells) to support this task. Our results indicated that developers could benefit from this type of symptom when smell occurrences affect the same program location and form a pattern; i.e., a set of co-occurring maintainability smells may better indicate the presence of a design problem. Nevertheless, we also reveal the limitations of relying solely on this type of symptom, highlighting the need for additional context. This leads us to the second study, where we investigate an additional type of symptom, robustness smells, and its combined use with maintainability smells. Our results indicated that the use of both types of smells can help developers in the identification of design problems mainly related to bad modularization of the system (e.g. excess of responsibilities assigned to the same component). Through these two studies, we observed the need to understand the perspectives and strategies of developers toward the NFRs of the system. In doing so, we can potentially understand who are the developers better able to prevent, discuss and identify design problems. That led us to our third study, where we investigated how developers discuss and address NFRs in their systems, uncovering common strategies toward these requirements. These results led us to a more comprehensive understanding of how developers can combine different symptoms and how they perceive their significance within their systems.

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.

Les changements sont faits de façon continue dans le code source des logiciels pour prendre en compte les besoins des clients et corriger les fautes. Les changements continus peuvent conduire aux défauts de code et de conception. Les défauts de conception sont des mauvaises solutions à des problèmes récurrents de conception ou d’implémentation, généralement dans le développement orienté objet. Au cours des activités de compréhension et de changement et en raison du temps d’accès au marché, du manque de compréhension, et de leur expérience, les développeurs ne peuvent pas toujours suivre les normes de conception et les techniques de codage comme les patrons de conception. Par conséquent, ils introduisent des défauts de conception dans leurs systèmes. Dans la littérature, plusieurs auteurs ont fait valoir que les défauts de conception rendent les systèmes orientés objet plus difficile à comprendre, plus sujets aux fautes, et plus difficiles à changer que les systèmes sans les défauts de conception. Pourtant, seulement quelques-uns de ces auteurs ont fait une étude empirique sur l’impact des défauts de conception sur la compréhension et aucun d’entre eux n’a étudié l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes. Dans cette thèse, nous proposons trois principales contributions. La première contribution est une étude empirique pour apporter des preuves de l’impact des défauts de conception sur la compréhension et le changement. Nous concevons et effectuons deux expériences avec 59 sujets, afin d’évaluer l’impact de la composition de deux occurrences de Blob ou deux occurrences de spaghetti code sur la performance des développeurs effectuant des tâches de compréhension et de changement. Nous mesurons la performance des développeurs en utilisant: (1) l’indice de charge de travail de la NASA pour leurs efforts, (2) le temps qu’ils ont passé dans l’accomplissement de leurs tâches, et (3) les pourcentages de bonnes réponses. Les résultats des deux expériences ont montré que deux occurrences de Blob ou de spaghetti code sont un obstacle significatif pour la performance des développeurs lors de tâches de compréhension et de changement. Les résultats obtenus justifient les recherches antérieures sur la spécification et la détection des défauts de conception. Les équipes de développement de logiciels doivent mettre en garde les développeurs contre le nombre élevé d’occurrences de défauts de conception et recommander des refactorisations à chaque étape du processus de développement pour supprimer ces défauts de conception quand c’est possible. Dans la deuxième contribution, nous étudions la relation entre les défauts de conception et les fautes. Nous étudions l’impact de la présence des défauts de conception sur l’effort nécessaire pour corriger les fautes. Nous mesurons l’effort pour corriger les fautes à l’aide de trois indicateurs: (1) la durée de la période de correction, (2) le nombre de champs et méthodes touchés par la correction des fautes et (3) l’entropie des corrections de fautes dans le code-source. Nous menons une étude empirique avec 12 défauts de conception détectés dans 54 versions de quatre systèmes: ArgoUML, Eclipse, Mylyn, et Rhino. Nos résultats ont montré que la durée de la période de correction est plus longue pour les fautes impliquant des classes avec des défauts de conception. En outre, la correction des fautes dans les classes avec des défauts de conception fait changer plus de fichiers, plus les champs et des méthodes. Nous avons également observé que, après la correction d’une faute, le nombre d’occurrences de défauts de conception dans les classes impliquées dans la correction de la faute diminue. Comprendre l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes est important afin d’aider les équipes de développement pour mieux évaluer et prévoir l’impact de leurs décisions de conception et donc canaliser leurs efforts pour améliorer la qualité de leurs systèmes. Les équipes de développement doivent contrôler et supprimer les défauts de conception de leurs systèmes car ils sont susceptibles d’augmenter les efforts de changement. La troisième contribution concerne la détection des défauts de conception. Pendant les activités de maintenance, il est important de disposer d’un outil capable de détecter les défauts de conception de façon incrémentale et itérative. Ce processus de détection incrémentale et itérative pourrait réduire les coûts, les efforts et les ressources en permettant aux praticiens d’identifier et de prendre en compte les occurrences de défauts de conception comme ils les trouvent lors de la compréhension et des changements. Les chercheurs ont proposé des approches pour détecter les occurrences de défauts de conception, mais ces approches ont actuellement quatre limites: (1) elles nécessitent une connaissance approfondie des défauts de conception, (2) elles ont une précision et un rappel limités, (3) elles ne sont pas itératives et incrémentales et (4) elles ne peuvent pas être appliquées sur des sous-ensembles de systèmes. Pour surmonter ces limitations, nous introduisons SMURF, une nouvelle approche pour détecter les défauts de conception, basé sur une technique d’apprentissage automatique — machines à vecteur de support — et prenant en compte les retours des praticiens. Grâce à une étude empirique portant sur trois systèmes et quatre défauts de conception, nous avons montré que la précision et le rappel de SMURF sont supérieurs à ceux de DETEX et BDTEX lors de la détection des occurrences de défauts de conception. Nous avons également montré que SMURF peut être appliqué à la fois dans les configurations intra-système et inter-système. Enfin, nous avons montré que la précision et le rappel de SMURF sont améliorés quand on prend en compte les retours des praticiens. / Changes are continuously made in the source code to take into account the needs of the customers and fix the faults. Continuous change can lead to antipatterns and code smells, collectively called “design smells” to occur in the source code. Design smells are poor solutions to recurring design or implementation problems, typically in object-oriented development. During comprehension and changes activities and due to the time-to-market, lack of understanding, and the developers’ experience, developers cannot always follow standard designing and coding techniques, i.e., design patterns. Consequently, they introduce design smells in their systems. In the literature, several authors claimed that design smells make object-oriented software systems more difficult to understand, more fault-prone, and harder to change than systems without such design smells. Yet, few of these authors empirically investigate the impact of design smells on software understandability and none of them authors studied the impact of design smells on developers’ effort. In this thesis, we propose three principal contributions. The first contribution is an empirical study to bring evidence of the impact of design smells on comprehension and change. We design and conduct two experiments with 59 subjects, to assess the impact of the composition of two Blob or two Spaghetti Code on the performance of developers performing comprehension and change tasks. We measure developers’ performance using: (1) the NASA task load index for their effort; (2) the time that they spent performing their tasks; and, (3) their percentages of correct answers. The results of the two experiments showed that two occurrences of Blob or Spaghetti Code design smells impedes significantly developers performance during comprehension and change tasks. The obtained results justify a posteriori previous researches on the specification and detection of design smells. Software development teams should warn developers against high number of occurrences of design smells and recommend refactorings at each step of the development to remove them when possible. In the second contribution, we investigate the relation between design smells and faults in classes from the point of view of developers who must fix faults. We study the impact of the presence of design smells on the effort required to fix faults, which we measure using three metrics: (1) the duration of the fixing period; (2) the number of fields and methods impacted by fault-fixes; and, (3) the entropy of the fault-fixes in the source code. We conduct an empirical study with 12 design smells detected in 54 releases of four systems: ArgoUML, Eclipse, Mylyn, and Rhino. Our results showed that the duration of the fixing period is longer for faults involving classes with design smells. Also, fixing faults in classes with design smells impacts more files, more fields, and more methods. We also observed that after a fault is fixed, the number of occurrences of design smells in the classes involved in the fault decreases. Understanding the impact of design smells on development effort is important to help development teams better assess and forecast the impact of their design decisions and therefore lead their effort to improve the quality of their software systems. Development teams should monitor and remove design smells from their software systems because they are likely to increase the change efforts. The third contribution concerns design smells detection. During maintenance and evolution tasks, it is important to have a tool able to detect design smells incrementally and iteratively. This incremental and iterative detection process could reduce costs, effort, and resources by allowing practitioners to identify and take into account occurrences of design smells as they find them during comprehension and change. Researchers have proposed approaches to detect occurrences of design smells but these approaches have currently four limitations: (1) they require extensive knowledge of design smells; (2) they have limited precision and recall; (3) they are not incremental; and (4) they cannot be applied on subsets of systems. To overcome these limitations, we introduce SMURF, a novel approach to detect design smells, based on a machine learning technique—support vector machines—and taking into account practitioners’ feedback. Through an empirical study involving three systems and four design smells, we showed that the accuracy of SMURF is greater than that of DETEX and BDTEX when detecting design smells occurrences. We also showed that SMURF can be applied in both intra-system and inter-system configurations. Finally, we reported that SMURF accuracy improves when using practitioners’ feedback.

No description available.

Les systèmes logiciels sont devenus de plus en plus répondus et importants dans notre société. Ainsi, il y a un besoin constant de logiciels de haute qualité. Pour améliorer la qualité de logiciels, l’une des techniques les plus utilisées est le refactoring qui sert à améliorer la structure d'un programme tout en préservant son comportement externe. Le refactoring promet, s'il est appliqué convenablement, à améliorer la compréhensibilité, la maintenabilité et l'extensibilité du logiciel tout en améliorant la productivité des programmeurs. En général, le refactoring pourra s’appliquer au niveau de spécification, conception ou code. Cette thèse porte sur l'automatisation de processus de recommandation de refactoring, au niveau code, s’appliquant en deux étapes principales: 1) la détection des fragments de code qui devraient être améliorés (e.g., les défauts de conception), et 2) l'identification des solutions de refactoring à appliquer. Pour la première étape, nous traduisons des régularités qui peuvent être trouvés dans des exemples de défauts de conception. Nous utilisons un algorithme génétique pour générer automatiquement des règles de détection à partir des exemples de défauts. Pour la deuxième étape, nous introduisons une approche se basant sur une recherche heuristique. Le processus consiste à trouver la séquence optimale d'opérations de refactoring permettant d'améliorer la qualité du logiciel en minimisant le nombre de défauts tout en priorisant les instances les plus critiques. De plus, nous explorons d'autres objectifs à optimiser: le nombre de changements requis pour appliquer la solution de refactoring, la préservation de la sémantique, et la consistance avec l’historique de changements. Ainsi, réduire le nombre de changements permets de garder autant que possible avec la conception initiale. La préservation de la sémantique assure que le programme restructuré est sémantiquement cohérent. De plus, nous utilisons l'historique de changement pour suggérer de nouveaux refactorings dans des contextes similaires. En outre, nous introduisons une approche multi-objective pour améliorer les attributs de qualité du logiciel (la flexibilité, la maintenabilité, etc.), fixer les « mauvaises » pratiques de conception (défauts de conception), tout en introduisant les « bonnes » pratiques de conception (patrons de conception). / Software systems have become prevalent and important in our society. There is a constant need for high-quality software. Hence, to improve software quality, one of the most-used techniques is the refactoring which improves design structure while preserving the external behavior. Refactoring has promised, if applied well, to improve software readability, maintainability and extendibility while increasing the speed at which programmers can write and maintain their code. In general, refactoring can be performed in various levels such as the requirement, design, or code level. In this thesis, we mainly focus on the source code level where automated refactoring recommendation can be performed through two main steps: 1) detection of code fragments that need to be improved/fixed (e.g., code-smells), and 2) identification of refactoring solutions to achieve this goal. For the code-smells identification step, we translate regularities that can be found in such code-smell examples into detection rules. To this end, we use genetic programming to automatically generate detection rules from examples of code-smells. For the refactoring identification step, a search-based approach is used. The process aims at finding the optimal sequence of refactoring operations that improve software quality by minimizing the number of detected code-smells while prioritizing the most critical ones. In addition, we explore other objectives to optimize using a multi-objective approach: the code changes needed to apply refactorings, semantics preservation, and the consistency with development change history. Hence, reducing code changes allows us to keep as much as possible the initial design. On the other hand, semantics preservation insures that the refactored program is semantically coherent, and that it models correctly the domain-semantics. Indeed, we use knowledge from historical code change to suggest new refactorings in similar contexts. Furthermore, we introduce a novel multi-objective approach to improve software quality attributes (i.e., flexibility, maintainability, etc.), fix “bad” design practices (i.e., code-smells) while promoting “good” design practices (i.e., design patterns).

Bons códigos importam, mas como saber quando a qualidade está baixa? Maus cheiros de código, ou anomalias, auxiliam desenvolvedores na identificação de trechos de código problemáticos, porém a maioria dos maus cheiros catalogados são voltados para práticas e tecnologias tradicionais, criadas entre as décadas de 70 a 90, como orientação a objetos e Java. Ainda há dúvidas sobre maus cheiros em tecnologias que surgiram na última década, como o Android, principal plataforma móvel em 2017 com mais de 86% de participação de mercado. Alguns pesquisadores derivaram maus cheiros Android relacionados à eficiência e à usabilidade. Outros notaram que maus cheiros específicos ao Android são muito mais frequentes nos aplicativos do que maus cheiros tradicionais. Diversas pesquisas concluíram que os componentes Android mais afetados por maus cheiros tradicionais são Activities e Adapters, que pertencem à camada de apresentação. Notou-se também que em alguns aplicativos, códigos da camada de apresentação representam a maior parte do código do projeto. Vale ressaltar que a camada de apresentação Android também é composta por arquivos XML, chamados de recursos, usados na construção da interface do usuário (User Interface - UI), porém nenhuma das pesquisas citadas os considerou em suas análises. Nesta dissertação, investigamos a existência de maus cheiros relacionados à camada de apresentação Android considerando inclusive os recursos. Fizemos isso através de dois questionários e um experimento de código online, totalizando a participação de 316 desenvolvedores. Nossos resultados mostram a existência de uma percepção comum entre desenvolvedores sobre más práticas no desenvolvimento da camada de apresentação Android. Nossas principais contribuições são um catálogo com 20 maus cheiros da camada de apresentação Android e uma análise estatística da percepção de desenvolvedores sobre os 7 principais maus cheiros catalogados. Nossas contribuições servirão a pesquisadores como ponto de partida para a definição de heurísticas e implementação de ferramentas automatizadas e a desenvolvedores como auxílio na identificação de códigos problemáticos, ainda que de forma manual. / We are aware that good code matters, but how to know when quality is low? Code smells, or anomalies, help us identify problematic code snippets, but most of the code smells cataloged are based on traditional practices and technologies, created from the 70s through the 90s, such as object oriented programming and Java. There are still doubts about code smells in technologies that have emerged in the last decade, such as Android, the main mobile platform in 2017 with more than 86% market share. Some researchers have defined code smells related to Android efficiency and usability. Other research concludes that the components most affected by traditional code smells are related to the front-end components, such as Activities and Adapters. Also noticed in some applications, front-end code represent the larger part of the projects code. It is worth mentioning that the Android presentation layer is also composed of XML files, called resources, used to build the user interface (UI), but none of the cited research considered them in their analyzes. In this dissertation, we investigate the existence of code smells related to the Android front-end, including application resources. We performed two online surveys and one online code experiment, summing 316 developers. Our results show that there is a common perception among Android developers about bad practices on Android front-end. Our main contributions are a catalog of 20 code smells related to the Android front-end and a statistical analysis of the perceptions of developers about the 7 main code smells cataloged. Our contributions will provide to researchers a starting point for the definition of heuristics and implementation of automated tools and to developers as an aid in identifying problematic codes.