https://abapinho.com/en/categories/boaspracticas/Recent content in boaspracticas on AbapinhoHugo -- gohugo.ioen©2009-2026 Nuno GodinhoMon, 06 Jul 2015 09:00:46 +0000https://abapinho.com/en/2015/07/tenta-converter-writes-para-alvs/Mon, 06 Jul 2015 09:00:46 +0000https://abapinho.com/en/2015/07/tenta-converter-writes-para-alvs/Reports still writing directly to the screen are very hard to maintain whenever changes to the layout are required. On such occasions, review the code and, if the effort involved is not too big, consider converting it to ALV. Always involve the functional people in this decision.https://abapinho.com/en/2015/05/encapsularas-encapsularas-encapsularas/Mon, 11 May 2015 11:40:10 +0000https://abapinho.com/en/2015/05/encapsularas-encapsularas-encapsularas/Historically ABAP programs tend to grow very loooong. All programming best practices teach us there is not a single advantage in this approach. If any routine, be it a program, a method, a function or anything else, becomes longer than 200-300 lines, question it and seriously consider refactoring it into several sub-routines. This has the added advantage of potentially increasing code reuse. But the greatest advantage is encapsulation, isolating variables in their local context, instead of having all of them together, resulting in safer and more readable code.https://abapinho.com/en/2015/05/reutilizaras-nao-reescreveras/Mon, 04 May 2015 09:00:28 +0000https://abapinho.com/en/2015/05/reutilizaras-nao-reescreveras/If the same piece of code is repeated at least once, question yourself why and try to avoid it by creating a reusable routine. If there is more than one SELECT for the same table in a program, make sure you can’t merge them into a single one. Sometimes a smart use of RANGEs to unify parameters can avoid the need for multiple SELECTs. If the same code is used in 2 different programs, don’t repeat the code.https://abapinho.com/en/2015/04/evitaras-variaveis-globais/Mon, 13 Apr 2015 09:00:36 +0000https://abapinho.com/en/2015/04/evitaras-variaveis-globais/The more global variables a program has, the most obscure it becomes. Please avoid them. This is a basic rule of good programming and should always be followed. Even if several variables have to be passed by parameter, it takes slightly more effort but yields a much more readable and safer code. Exceptions can be made for simple reports which run around a single internal table, which can be declared globally without compromising clarity.https://abapinho.com/en/2015/03/usaras-sempre-uma-estrutura-pre-definida-nas-alvs/Mon, 16 Mar 2015 09:00:30 +0000https://abapinho.com/en/2015/03/usaras-sempre-uma-estrutura-pre-definida-nas-alvs/It is common to find an ALV data structure explicitly defined in the code. If this is done, the field catalog has to be manually constructed. If a predefined structure (from DDIC or declared as a TYPE) is used instead, the field catalog can be automatically built. This approach is always better and results in less code, even if the field catalog needs to be adjusted here and there. https://abapinho.com/en/2011/12/automatizar-catalogo-alv/https://abapinho.com/en/2015/03/usaras-transporting-no-fields/Mon, 09 Mar 2015 09:00:02 +0000https://abapinho.com/en/2015/03/usaras-transporting-no-fields/Many times we do READ TABLE itbl or LOOP AT itbl just to do a CHECK SY-SUBRC = 0. In these cases, the actual data read is not needed. For these cases always use TRANSPORTING NO FIELDS. This way is faster and avoids having to declare a target structure.https://abapinho.com/en/2015/01/usaras-classes-de-excepcao/Thu, 22 Jan 2015 09:00:28 +0000https://abapinho.com/en/2015/01/usaras-classes-de-excepcao/In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code. https://zevolving.com/2011/12/class-based-exception/https://abapinho.com/en/2015/01/usaras-literais-prontos-a-traduzir-nos-programas/Tue, 13 Jan 2015 10:13:48 +0000https://abapinho.com/en/2015/01/usaras-literais-prontos-a-traduzir-nos-programas/In reports, instead of WRITE TEXT-001, use WRITE ‘bla bla bla’(001). This way a default text will always be there and besides the readability of the program is improved. https://abapinho.com/en/2011/11/programas-poliglotas/https://abapinho.com/en/2015/01/usaras-a-salv-em-vez-das-antigas-funcoes-de-alv/Thu, 08 Jan 2015 09:00:37 +0000https://abapinho.com/en/2015/01/usaras-a-salv-em-vez-das-antigas-funcoes-de-alv/SALV classes are more versatile and more recent than the old function modules. So, for new ALVs always use SALV. The only exception is editable ALVs which SALV classes are still very incapable of doing. https://scn.sap.com/docs/DOC-10365 https://scn.sap.com/docs/DOC-10366https://abapinho.com/en/2014/11/inner-join-vs-for-all-entries-vs-ranges-artificiais/Tue, 25 Nov 2014 09:00:13 +0000https://abapinho.com/en/2014/11/inner-join-vs-for-all-entries-vs-ranges-artificiais/Since data operations are much more optimized in the database server than in ABAP, it is always better to use the first as much as possible. FOR ALL ENTRIES should only be used when INNER JOIN doesn’t give us what we need or is not possible (like with BSEG for example). Artificial ranges are also a possible alternative to FOR ALL ENTRIES but be careful not to reach the SQL parser limit.https://abapinho.com/en/2014/11/nao-usaras-checks-directamente-em-user-exits/Mon, 10 Nov 2014 09:00:51 +0000https://abapinho.com/en/2014/11/nao-usaras-checks-directamente-em-user-exits/User-exits (and enhancements) are usually crowded with CHECKs. The tragic consequence is that, if the check fails, nothing else after it will run. Not even the standard code. Always try to correct these. Encapsulating the code inside a routine (ideally a method) is enough to render it harmless.https://abapinho.com/en/2014/10/usaras-like-line-of-itbl/Mon, 20 Oct 2014 10:25:10 +0000https://abapinho.com/en/2014/10/usaras-like-line-of-itbl/When declaring structures which will receive data from an internal table, instead of declaring its type directly, use LIKE LINE OF. This way not only it becomes clear that they are related but also, if you happen to change the type of the internal table, you won’t have to worry about updating the structure’s type.https://abapinho.com/en/2014/09/nao-faras-commit-em-user-exits/Mon, 29 Sep 2014 09:00:25 +0000https://abapinho.com/en/2014/09/nao-faras-commit-em-user-exits/Never do COMMITs inside user-exits. Also, make sure any external routine you call from there doesn’t do any COMMIT either.https://abapinho.com/en/2014/09/consideraras-usar-clusters-sm34/Thu, 11 Sep 2014 09:00:14 +0000https://abapinho.com/en/2014/09/consideraras-usar-clusters-sm34/If a development requires more than one customising table consider grouping their maintenance views under a cluster. This way it will be more intuitive to maintain them. This makes even more sense if one depends on the other since in the cluster definition these relations can be explicitly defined. Example: Como encavalitar tabelas (portuguese)https://abapinho.com/en/2014/09/nao-facas-select-asterisco/Thu, 04 Sep 2014 11:25:03 +0000https://abapinho.com/en/2014/09/nao-facas-select-asterisco/Always try to select only the fields you’ll need. Selecting others is a waste of resources. Exception made for the use of FM *_SINGLE_READ because, even though these do select all fields, since they cache the data, they are still faster when used multiple times for the same key. If you just want to check if a record exists, select just one field, if possible the one you’re using as criteria to avoid declaring an extra variable.https://abapinho.com/en/2014/08/usa-uma-tabela-de-constantes/Thu, 28 Aug 2014 09:00:45 +0000https://abapinho.com/en/2014/08/usa-uma-tabela-de-constantes/Whenever you feel a constant value can change and you can’t add it as a user parameter, store it in ZCONSTS. This table should never be used directly. Instead, a class like ZCL_CONSTS should be created to properly access it, like shown in this article: (portuguese only) Resist the temptation of using T900 or similar tables for this purpose. It’s true that a lot of people do it. But it’s ugly, durty and besides these tables don’t even have an adequate key because they were not designed with this in mind.https://abapinho.com/en/2014/08/cria-e-adopta-bibliotecas-de-ferramentas-comuns/Thu, 21 Aug 2014 09:00:04 +0000https://abapinho.com/en/2014/08/cria-e-adopta-bibliotecas-de-ferramentas-comuns/Code which is used very often should be made available centrally, if possible under a single package (ex: ZTOOLS) so that it’s easily identified. There is a lot of code already available on the Internet to accomplish several common functions (ex: ABAP2XLSX). Adopt it; For your most common tasks, develop your own tools which you can reuse and add them to the central library; Advertise the existence of that library among your colleagues to avoid that they waste time come up with duplicate code wasting;https://abapinho.com/en/2014/08/nao-substituiras-simplesmente-por/Fri, 08 Aug 2014 09:00:08 +0000https://abapinho.com/en/2014/08/nao-substituiras-simplesmente-por/If you need to adapt the content of a file with amounts, always take into consideration the user settings (USR01-DSCFM). If you need to convert a string to a number use FM MOVE_CHAR_TO_NUM. If you need to convert a number to a string use WRITE curr TO str [CURRENCY waers].https://abapinho.com/en/2014/07/usaras-o-comando-tables-so-quando-inevitavel/Thu, 31 Jul 2014 09:00:20 +0000https://abapinho.com/en/2014/07/usaras-o-comando-tables-so-quando-inevitavel/Using SELECT-OPTIONS is one of the very few reasons for using TABLES. For all other cases, explicitly declare a local variable for the equivalent structure. TABLES basically creates obscure global variables which increase ambiguity in the code. And global variables should be avoided anyway.https://abapinho.com/en/2014/07/usaras-field-symbols-em-vez-de-variaveis-de-estrutura/Thu, 24 Jul 2014 09:00:50 +0000https://abapinho.com/en/2014/07/usaras-field-symbols-em-vez-de-variaveis-de-estrutura/READ TABLE itbl ASSIGNING is always faster than READ TABLE itbl INTO wa. Besides, when making changes to internal tables, not only it doesn’t require the explicit MODIFY but it also does away with the auxiliary TABIX variable. The only situation in which a working area is better is when adding new lines to an internal table. Some people contend that working areas should still be used when no changes are to be made to the data.https://abapinho.com/en/2014/07/agruparas-partes-que-estejam-relacionadas/Thu, 17 Jul 2014 09:00:16 +0000https://abapinho.com/en/2014/07/agruparas-partes-que-estejam-relacionadas/Sometimes you find an IMPORT in the code but you have no idea where the corresponding EXPORT is. When communication is needed between programs, it should be done using a pair of methods belonging to the same class. This way, when we run into one, we’ll always know where the other one is. Anyway, try to use EXPORT/IMPORT only when unavoidable. If possible, use static class variables instead.https://abapinho.com/en/2014/07/evitaras-mensagens-dinamicas/Thu, 10 Jul 2014 08:30:17 +0000https://abapinho.com/en/2014/07/evitaras-mensagens-dinamicas/When you need to send a dynamic message by parameter, make sure you still use the MESSAGE command, so that the “where-used” doesn’t loose track of it. When you do MESSAGE E001 INTO V_DUMMY, the message details become available in the system variables: SY-MSGNO, SY-MSGTY, etc. Also, message texts should never be hardcoded, they should always be defined in SE91. https://abapinho.com/en/2009/09/evitar-mensagens-dinamicas/ (portuguese)https://abapinho.com/en/2014/06/nao-implementaras-codigo-em-user-exits-badis-enhancements-etc/Thu, 26 Jun 2014 09:00:47 +0000https://abapinho.com/en/2014/06/nao-implementaras-codigo-em-user-exits-badis-enhancements-etc/All code to be put in user-exits (BADIs, enhancements, SMOD, etc.) should be encapsulated. It’s common for an user-exit to include multiple independent parts. Each of these parts should be encapsulated in its own method. Even if it is only one line; This should apply to both new implementations and changes to existing code; A change to existing code should always be seen as an opportunity to organize existing code into methods, since it will have to be tested again anyway;https://abapinho.com/en/2014/06/nao-implementaras-blocos-de-processamento-classico/Thu, 19 Jun 2014 09:00:32 +0000https://abapinho.com/en/2014/06/nao-implementaras-blocos-de-processamento-classico/Official ABAP Programming Guidelines (page 34): [When a classical processing block is required], you should immediately delegate the execution to a suitable method (see Rule 6.37, No Implementations in Function Modules and Subroutines, and Rule 6.44, No Implementations in Dialog Modules and Event Blocks).https://abapinho.com/en/2014/06/usa-abap-oo-sempre-que-possivel/Tue, 10 Jun 2014 13:14:29 +0000https://abapinho.com/en/2014/06/usa-abap-oo-sempre-que-possivel/All new developments should be implemented using ABAP Objects unless still impossible (RFC, IN UPDATE TASK, screens, etc). Existing developments, when rewritten, should also be converted to OO, if it proves to be realistic. Official ABAP Programming Guidelines (page 32) rule 3.1: Use ABAP Objects whenever possible for new and further developments. Classical processing blocks may be newly created in exceptional cases only. pdf/why-abap-objects.pdf https://scn.sap.com/people/thomas.jung/blog/2007/12/19/update-your-abap-development-skills-to-sap-netweaver-70 https://wiki.sdn.sap.com/wiki/display/ABAP/ABAP+Objects