![]() ![]() ![]() ![]() In fact, the only place where you could use the continuation character has to be where a space, tab, or line feed, or enter key could be used without altering the reconstruction of the line in any way. Since the combined result would be 123 4567 with a whitespace included, and would be parsed as two different numbers (usualling resulting in an error as well) Nor do you break up number sequences, such as Should Else_īe recognized as ElseIf or Else_If, a legal name construct? Rm, because this could change the meaning of the word or term. For instance, it cannot be used in the middle of a word or te_ (Actually, it is the use of a whitespace_underscore_whitespace sequence, making it different from the leading underscore_name or underscore used in names such as this_could_be_a_name construct).Ĭould represented a line continuance. A couple of languages have used the underscore (_) character, and I myself find this works very well. The final compromise seems to be the emerging need for a line continuation character. The preference was to have one line viewed as one line. In fact, these had been tried on occasion, but the results were often less readability. But long procedure, constant, and variable names introduced a new problem: Lines became longer and longer, and there was no line wrap capability in the editors or viewers. It still allowed you to use short local names with the "Alias" convention, but increasingly, programmers have decided that it was generally better to use the original name, so that as they became familiar with the Windows APIs, they did not need to try to remember any local names for those functions as well. Now the names had to be long, case sensitive, and somewhat self-documenting. MicroSoft changed that with its Windows API constants and functions. That means that most statements tend to be short, and even long ones are not overly long. But the need for a line continuation character has not been universally established, because old habits die hard, and most programmers prefer short names for their variables and lables, and relatively terse code. Later, the use of the colon (:) was added so that you could have more than one statement per line, in the interest of compressing programs even more (memory was short, and it generally too an additional 5 bytes to mark a new line and line number). BASIC syntax is that you have one statement per line. Knowith this, or at least somewhataware of this, we see that the way we compose source code is somewhat different. And the use of all capatal letteres is NEVER done, unless we intend to exaggerate something. Nor do we see that words are only occasionally preceeded by a capital letter, and then only at the start of a new sentance or for formal names or to Emphasize something. Nor do we have the pleasure of knowing that words are principally lower-case letters without embedded punctuation or digits. But unlike normal text, we do not have the convenienct of using a period (.) to indicate where a line ends. Go back are read what I have said, and you will see that never once did say anything to that effect. You seem to think I am against line continuation, but you misconstrue my remarks. (Because of some side effects, at the line is actually better than at the beginning). That is where I showed the use of a separate underscore (_) character at the end (or the beginning) of a line. on the other hand, pointed out that a line continuation symbol was needed in order to allow lines, rather than words, to lap over to other lines. Returns to be placed in them (at least that is what his example showd). On one hand, someone advocated breaking up words by allowing spaces or I see the need for a continuation method. That imposes some penalty on the language as to when a statement actually ends, which means a lot of right parens or curly brackets running around trying to join up with a leading left paren or curly bracket somewhere above in the code. Now in C/C++, spaces, tabs, and newlines are all treated as white space. Text more readable, and lables or terms get longer and longer. Such techniques become ever more important as you attempt to make the _ to show that this line joins to the one above. Is suppose to be an "EndIf" or and "End" command that preceeds an "If".Īnd if it's decision does not agree with your intent, then how are you going to find the line that is being misconstrued?īut while you can read the above well enough, since your mind makes the connection that this is a single statement, the compiler does not have the luxury of always knowing what you meant, only what you signify by the text you enter. In addition, it also makes the files bigger and puts a much greater demand on the compiler. So why would you want to haphazardly put spaces or new lines into terms and commands - just to prove that you can? That serves no purpose, and onlyh makes it harder to read and maintain your code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |