There is already a standard code style
As François Piette (a very honourable Embarcadero MVP) recently wrote, coding style matters. He states “… this is mostly a matter of personal preferences as long as the style is constant…” but I totally disagree in this very important topic: there shouldn’t be any “personal preferences” in writing code.
And I am speaking now solely about coding style in terms of notation, indentation and not about naming conventions for variables, methods, etc – please bear with me – as this is even a more complex issue:
Yes, there is a standard: use CTRL + D and the IDE reformats your code to the proposed standard. If you don’t have this menu item in your ‘Edit’-menu, you’re using a very very old Delphi version (thus any following conversation doesn’t interest me at all, and you may skip reading this post, thank you).
Following this code standard is vital to any team success – there shouldn’t be any personal preference whilst coding in a team. And even if you are a single developer, you should obey this standard: if you’re used to read your code style only, you may have a hard time to read others’ code on the web or – more likely – code found in the VCL sources (and yes, they are not *that* consistent like they should).
Example unformatted / personal Delphi code style
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Function getCount( Const value : integer ):integer; Var i : integer; j : integer; Begin j:=0; for i:= 0 to value do begin j:=j*otherFunc( Value , 50 ); j:=j*2; end; result:=j; End |
Example Delphi ‘standard’ code format
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
function GetCount(const Value: Integer): Integer; var I, J: Integer; begin J := 0; for I := 0 to Value do begin J := J * OtherFunc(Value, 50); J := J * 2; end; Result := J; end |
Btw, code formatting is not a task for the IDE, it should be the responsibility of the coder writing clean and readable code.
Following the ‘official’ standard
- helps you reading official sources
- helps you reading others sources
- helps others reading your sources
- helps beginners reading Delphi code
- helps beginners writing cleaner Delphi code
- helps teams writing a code writing conduct
- helps yourself as a new coding team member
helps the seahawks win the Super Bowl(done)
8 Comments to There is already a standard code style
> helps the seahawks win the Super Bowl (done)
if all would be that easy 🙂
February 4, 2014
What about those of us with a reading disability? I have overcome my problems with reading – but i typically break long sections of text into smaller chunks. This makes some programmers very “observant” of my code, as it looks more like C# or C++.
But i agree about the “if (something then begin”, that makes it so hard to analyze and understand large procedures (spaghetti code)
February 5, 2014
The IDE allows reformatting to your own (better readable) style, but when it comes to commiting your sources to a team server you should reformat them (by CTRL-D on a separate IDE for example) to the standard style before commiting – so you have your own style on your IDE but the others still have the standard code style.
February 5, 2014
And who sets this standard? Is it only valid for Embarcadero Delphi? Or does it cover FreePascal as well? What about Oxygene? Where can I find a document containing an “official standard” regarding, for example, passing closures? My XE5 likes to mess up stuff like TThread.CreateAnonymousThread(..).
Just declaring what your current IDE outputs after pressing CTRL+D seems a bit too easy for me. Arguing about whether a “begin” should be preceeded with a linebreak is like arguing whether to use tabs or spaces for indentation. The most important thing about a coding standard is that everybody involved sticks to it. And I strongly believe that when a team develops their very own coding style, there’s nothing wrong with it. So in the end: Yes, there is personal choice involved.
February 5, 2014
There is a DELPHI standard (I am not speaking about Oxygene or FPC) – which is defined by Embarcadero. Where? Take a look at the VCL sources. Take a look at the (rather old) code style doc on edn. Why should a Delphi Team follow the EMB-code style? Well, as I said: don’t your ever need to read the VCl sources? You have a hard time reading those if you’re used to read your own code style. Yes it is very easy to say “press ctrl-d” and that’s it. If the reformatter won’t work because of fluent interfaces, etc. and you have to reformat your source manually that’s quite ok. It’s the idea behind the code style: do not create your own, because there is already a standard. New team members have a hard time if you set a code style quite different to the standard (I’m not talking about minor changes, but indentation, spacing before and after variables and procedure calls/parameters and the position of “begin” and “end” is not a minor change for example).
February 5, 2014
Understood. But I honestly cannot accept the current Delphi RTL or VCL sources as a prime example of how you should format your sourcecode. I think a lot of that stuff is not readable at all. I’m probably too focued on the code itself rather than the formatting and the style itself.
Coming from C++ and Java, I have such a burning hatred for the omission of parentheses if a method has no parameters, it’s probably on the verge of a behavioural problem. We’re using camelCase, not PascalCase. And so on. I honestly do not consider strictly following a semi-official styleguide critical. To cut it short: Personally, I do not agree.
The “official” sources are horrible to read though I have to admit a lot of that is probably caused by the load of IFDEFS and bad code itself. We have adjusted to a formatting style that is way closer to the way everybody uses languages like C# or Java: camelCase for fields, PascalCase for properties (and freaking parentheses for methods!).
Cheers.
February 6, 2014
Hear, hear! I used to be a very vocal evangelist about some very specific code styles. Nowadays I just use what’s standard and can be forced on a team. Ctrl-D for me everywhere!
(Well, except when I use fluent interfaces.)
February 6, 2014
@Salmo: very interesting. I am using C# and C++ as well, and I’ll switch my code style while using that languages – in the very beginning I’ve written some macros which allowed me using BEGIN and END in C code, just because I was that used to see these as code block boundaries. But that was a looong time ago, and I have learned that you can adopt *any* code style even if you have used something very different for years – just try it and some “ugly” standard code will look quite normal after some weeks and you won’t ever return to your own style again.
@Leonardo: thank you!
Leave a comment
About Dennis D. Spreen
Search
Recent Posts
- How to compile Lua 5.4.0 for Android as a dynamic library using Android Studio 4
- Please make inline vars usable for production – fix RSP-28892
- How to compile Lua 5.4.0 as a Mac OS X dynamic library
- How to compile Lua 5.4.0 for Linux as a shared library
- How to compile Lua 5.4.0 for Windows
- Daily Wage – a Spigot/Bukkit plugin that pays out a daily wage
- How to compile Lua 5.3.5 for Windows
- Better Collada exporter for Blender with custom properties
- MOS6502-delphi – a MOS 6502 CPU emulator for Delphi
- Pass a multidimensional array as a parameter (with a hidden caveat)
Categories
Tags
Archives
- May 2020
- March 2020
- June 2019
- March 2017
- August 2016
- July 2016
- June 2016
- January 2016
- September 2015
- February 2015
- January 2015
- October 2014
- September 2014
- August 2014
- May 2014
- March 2014
- February 2014
- November 2011
- June 2011
- February 2011
- March 2010
- September 2009
- August 2009
- July 2009
- May 2009
- March 2009
- February 2009
- January 2009
- November 2008
- October 2008
- February 2008
- June 2007
Delphi Feeds
- How To Live Track The ISS International Space Station December 20, 2024
- SmartInspect 4 Beta 1 Released December 20, 2024
- Mastering FastReport in Delphi: Dynamic File Reporting and Visualization December 19, 2024
- This was 2024 overview December 19, 2024
- Mon bilan GitHub pour l'année 2024 December 19, 2024
- Re-Architecting Legacy Applications: Top Software Transformation December 18, 2024
- The Horror of finding the right database! Part 3 December 18, 2024
- Using TeeChart in Vector Magnetics’ RivCross Software for Precise Directional Drilling December 18, 2024
- Upgrading C++Builder 12.2: Tip #7, bcc64x tips! December 17, 2024
- Enhancing Delphi Code Safety: Best practices, tools, and context December 17, 2024
February 4, 2014