Let go of SE24

In SE24 the class code is partially hidden from the programmer behind a GUI. This is apparently convenient but ultimately limitative.
In SE24 the class code is partially hidden from the programmer behind a GUI. This is apparently convenient but ultimately limitative.
When a program is bad because it has duplicate code, it usually becomes shorter once we rewrite it to make it better. But, if its problem is not being properly structured into several classes and methods, if we rewrite it according to the best practices, it will probably end up longer.
After over 10 year using Wordpress, the world evolved and Abapinho decided it’s time to evolve with it.
Please stop. Too many regressions happen because someone forgets to CLEAR or to not CLEAR a variable.
Ok let’s go slowly on this one. Picture a scenario in which you have a customizing table with several levels of detail which may or may not be defined: BUKRS (empresa) WERKS (plant) LGORT (depósito) When one of the fields is empty, we treat it as a wildcard, meaning all values are valid.
After 10 years using Evernote, this year I finally started looking for better alternatives. At first Evernote was great. But it never evolved and the world moved on. So many new concepts have appeared: jardins digitais, backlinks, Zettelkasten, Evergreen notes, MOCs, etc. And Evernote is still the same, forcing you to be a note taker instead of a note maker.
One of the first posts in Abapinho was about Evernote. Well, it was actually about the importance of taking notes. But it suggested Evernote was the best tool for the job. It feels like yesterday but this was 10 years ago. 10 years using Evernote to take notes. Unfortunately whoever makes Evernote probably stopped taking notes many years ago because, since then, Evernote hardly evolved. Actually, it got worse, especially in its iOS version. After 10 years, they weren’t even able to (try to?) make a decent table editor. They’re either lazy or dumb.
If you regularly read Abapinho you probably know by now that I can’t live without ABAP Package Concept. Nowadays the first thing I do when starting a new development is creating an encapsulated package to hold all its objects (in the most complex scenarios, I create it as a main package and then create multiple child sub-packages). I lay here a modest proposal (unlike the original one, mine is not sarcastic) to help organize thing a bit at system level.
Some days ago I was using an ST (Simple Transformation) and thought that, even though its job is to convert an input into an output, it is can be used to store XML data. Let’s asy we have the following XML: <cocktails> <cocktail id=&quot;gt&quot; nome=&quot;Gin Tonic&quot;/> <cocktail id=&quot;ws&quot; nome=&quot;Whiskey Sour&quot;/> <cocktail id=&quot;cl&quot; nome=&quot;Campari Laranja&quot;/> </cocktails>
It happens very often that, while programming, I smell something strange. It’s usually hard to identify it right away. It usually starts like a faint fragrance. But, as I become more aware of it, eventually it starts stinking and I understand where it comes from. Even then it is not immediately clear why that particular thing smells bad.
Since 1998, I hear some ABAPer colleagues saying that it’s not worth encapsulating a particular piece of code in a function or method because it will never be reused again. And then they go to SE38 and create yet another report full of includes. The idea that you should encapsulate your code for it to be reused by you or by others is one of the biggest misunderstandings of the history of our planet.