

If you use this line and try to avoid surpassing this limit, your source code will look better when you print it on paper.

Unlike BASIC, Pascal allows you to write a statement on several lines of code, splitting a long instruction on two or more lines. White space is used only to improve code readability it does not affect the compilation. All these elements are collectively known as white space. Other elements completely ignored by the compiler are the spaces, new lines, and tabs you add to the source code. When an identifier is made up of several consecutive words (you cannot insert a space in an identifier), every first letter of a word should be capitalized: A common approach is to capitalize only the first letter of each identifier. Second, you should try to be consistent in the use of uppercase letters, to improve the readability of the code.Ī consistent use of case isn't enforced by the compiler, but it is a good habit to get into. First, you must be aware that these identifiers really are the same, so you must avoid using them as different elements. There are a couple of subtle drawbacks, however. Note: There is only one exception to the case-insensitive rule of Pascal: the Register procedure of a components' package must start with the uppercase R, because of a C++Builder compatibility issue. On the whole, this is definitely a positive, since in case-sensitive languages, many syntax errors are caused by incorrect capitalization. Therefore, the identifiers Myname, MyName, myname, myName, and MYNAME are all exactly equivalent. The Pascal compiler (unlike those in other languages) ignores the case (capitalization) of characters. It's both a valid directive and a comment, although sane programmers will probably tend to separate directives and comments. Note that if the open brace or parenthesis-star is followed by the dollar sign ($), it becomes a compiler directive, as in is legal. With a second comment identifier, you can write the following code, which is correct: If you want to comment out several lines of source code to disable them, and these lines contain some real comments, you cannot use the same comment identifier: Having three different forms of comments can be helpful for making nested comments.

In the listings of the book I'll try to mark comments as italic (and keywords in bold), to beĬonsistent with the default Delphi syntax highlighting. Comments up to the end of the line are very helpful for short comments and for commenting out a line of code. The third form of comments has been borrowed from C++ and is available only in the 32-bit versions of Delphi.

The second form was often preferred in Europe because many European keyboards lack the brace symbol. The first form is shorter and more commonly used. this is a comment up to the end of the line Delphi also accepts the C++ style comments, which can span to the end of the line: In Pascal, comments are enclosed in either braces or parentheses followed by a star. An essential tool for clarity is consistency-whatever style you choose, be sure to follow it throughout a project. The style and formatting decisions you make are a form of shorthand, indicating the purpose of a given piece of code. In general, the goal of any coding style is clarity. However, there are some principles you need to know regarding comments, uppercase, spaces, and the so-called pretty-printing. The question I'm addressing here is this: Besides the syntax rules, how should you write code? There isn't a single answer to this question, since personal taste can dictate different styles. The cover of the 4th edition of Essential Pascal,īefore we move on to the subject of writing Pascal language statements, it is important to highlight a couple of elements of Pascal coding style.
