 | Mike Verhagen on geerlingguy/my-backup-plan: Ho… |
 | Attila Kovacs on docs.embarcadero.com unreachab… |
 | David Blue on MacOS: converting a man page t… |
 | jpluimers on How do I pretty-print JSON in… |
| jpluimers on Delphi 10.2 Tokyo Godzilla ISO… |
Posted by jpluimers on 2019/10/17
There are many “code of conduct” documents. Often they differ a lot. I have my own: Do not be an asshole. Respect the others.
Source: [WayBack] My code of conduct – Marcin Juszkiewicz
Via: [WayBack] I like this code of conduct and general remarks. – Jean-Luc Aufranc – Google+
–jeroen
Posted in LifeHacker, Power User | Leave a Comment »
Posted by jpluimers on 2019/10/17
Still wrongly documented as System.Exit Function [WayBack], most people think it is a statement.
However, it is a compiler intrinsic procedure in the System unit that – when called inside a real function – optionally accepts a parameter with the same type as the encompassing function because it is a compiler intrinsic. It kind of acts as an overloaded procedure, but in fact translate to machine code via an intermediate parse tree.
The parameterless version has been there since at least Turbo Pascal 3.0, but the parameterised version is more recent: I think it was introduced around Delphi 7.
It then stops executing that function after first executing any explicit or implicit finally blocks.
I’ve seen various projects that used their own
Exitprocedure. This is a very bad habit: Since theSystemunit is always further away in scope, the introduced one is called which can severely confuse programmers not being aware of this.
The code generation for the parameterless and parameterised “overloads” of System.Exit is slightly different:
Stefan Glienke explained the above in [WayBack] The advantage of using Exit() instead of a plain Exit? You can place a breakpoint! – Uwe Raabe – Google+
–jeroen
Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | 1 Comment »
Posted by jpluimers on 2019/10/17
As a follow up of SSCCE, MWE and MCVE are basically the same: provide code people can use to reproduce a problem, I found [WayBack] How to debug small programs which is starts as
One of the most frequent categories of bad questions I see on StackOverflow is: I wrote this program for my assignment and it doesn’t work.
[20 lines of code].And… that’s it.
Then it goes on how to debug those pieces of code, trim them into an SSCCE/MWE/MCVW to form the base of a question which you can ask on StackOverflow/SuperUser/ServerFault/StackExchange, forum, group/community or even your co-worker.
The really cool thing about the techniques used there are that they also apply to bigger pieces of code, heck even large code bases.
They force you to trim down your problem in to manageable pieces that are easy to explain and write concise documentation and tests around them to assist you in the process.
Below are the steps in a short list. Be sure to read the original article How to debug small programs | Fabulous adventures in coding after going through the list.
This sounds like a lot of work. It is. All good programming is.
If you apply these before writing any logic code, then your life becomes easier because you will spot bugs sooner:
Does this again sound like a lot of work?
Then remember: taking a shortcut will make the actual work longer. The reason is that hunting for bugs is a tedious and time consuming process scaling very badly with complexity.
–jeroen
Posted in Conference Topics, Conferences, Debugging, Development, Event, Software Development | Leave a Comment »
The Wiert Corner - irregular stream of stuff 