Brackets or not

[RNBW]

One of the things I have never liked about modern programming languages is their use of brackets for the start and end of blocks of code. As I get older, my eyesight is worsening and it is only too easy to miss a bracket.

I remember when I first came across C a method to overcome this by defining { as begin and } as end.

I must say that I find it easier to use this method (I use endBegin rather than end) for my own use and then use Search and Replace to convert it back to brackets for others to see.

The following code demonstrates

  My method using begin and endBegin:

//*******************************************
// Filename: EnterNumeric_PAS_01.cpp
// This program accepts the entry of a
// number, formats it to two decimal
// places and displays the resuly.
//
// It replaces the brackets { } with
// begin and endBegin
//
//*******************************************

#include <cctype>
#include <string>
#include <iostream>
#include <iomanip>
#include <windows.h>

#define begin {
#define endBegin }

using namespace std;

TCHAR getkeypress()
  begin
     DWORD mode, count;
     HANDLE h = GetStdHandle( STD_INPUT_HANDLE );
     if (h == NULL) return 0;  // not a console
     GetConsoleMode( h, &mode );
     SetConsoleMode( h, mode & ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT) );
     TCHAR c = 0;
     ReadConsole( h, &c, 1, &count, NULL );
     SetConsoleMode( h, mode );
     return c;
  endBegin

double enterNumber(const string& prmp)
begin
	string num;

	cout << prmp;

	for (char ch; ((ch = getkeypress()) != '\n') && (ch != '\r');)
		if (isdigit(ch) || ((ch == '.') && (num.find('.') == string::npos)) || ((ch == '-') && num.empty()))
         begin
			num += ch;
			cout << ch;
		endBegin
		else
			if ((ch == '\b') && !num.empty())
			begin
				cout << ch << ' ' << ch;
				num.erase(prev(num.end()));
			endBegin
			else
				if (ch != '\b')
					cout << '\a';

	return num.empty() ? 0.0 : stod(num);
endBegin

int main()
begin
	double number = enterNumber("Enter a number: ");
	cout << "\nNumerical input: " << fixed << setprecision(2) << number;
endBegin

The normal C++ code would be:

#include <cctype>
#include <string>
#include <iostream>
#include <iomanip>
#include <windows.h>

using namespace std;

// This code from Duthomhas in CPlusPlus Forum
// 18 August 2008
TCHAR getkeypress()
  {
  DWORD mode, count;
  HANDLE h = GetStdHandle( STD_INPUT_HANDLE );
  if (h == NULL) return 0;  // not a console
  GetConsoleMode( h, &mode );
  SetConsoleMode( h, mode & ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT) );
  TCHAR c = 0;
  ReadConsole( h, &c, 1, &count, NULL );
  SetConsoleMode( h, mode );
  return c;
  }

double enterNumber(const string& prmp)
{
	string num;

	cout << prmp;

	for (char ch; ((ch = getkeypress()) != '\n') && (ch != '\r');)
		if (isdigit(ch) || ((ch == '.') && (num.find('.') == string::npos)) || ((ch == '-') && num.empty())) {
			num += ch;
			cout << ch;
		} else
			if ((ch == '\b') && !num.empty()) {
				cout << ch << ' ' << ch;
				num.erase(prev(num.end()));
			} else
				if (ch != '\b')
					cout << '\a';

	return num.empty() ? 0.0 : stod(num);
}

int main()
{

	//auto number =enterNumber("Enter a number: ");
	double number =enterNumber("Enter a number: ");

	cout << "\nNumerical input: " << fixed << setprecision(2) << number;
}

I know that experienced coders do not like the method, but I have found it easier to use.

[jonnin]

Typing vs IDE.
no one wants to type 10 chars when 1 will do.
IDE highlights matched braces and indents and all for you.
therefore going pascal on it isn't helpful -- your code is going to be harder to read for anyone else.
My recommendation, for what its worth, is to do this if you like, and when you are done with a piece of code, just do a replace to put it back to C++ style, and reverse if you need to get it back.

[malibor]

matching brackets should not be problem, IDE should do that for you.
If not you should consider switching to better IDE or adjusting settings.

I have this problem only when cutting out and pasting chunks of code and accidentally cutting out few brackets more, but in all other cases not even thinking about these things.

[mbozzi]

Agree with @malibor.

IMO, one should only think about braces if they've lost track of the structure of their code and are looking for their place. The way to avoid this problem is to change the editing process.

I used to program Lisp, where it's common to end a function definition with a sequence of closing parens )))))))). Lisps may offer extreme examples, but anyone who tries to edit or read lisp code by counting those is going to have a bad time.

Fortunately, Lisp code is formatted religiously, so that its tree structure is always apparent through its indentation.

The solution for you, I think, is to take a similar approach:
- Keep single lines of code short. I prefer a hard limit of 80 characters per line; some may prefer slightly longer lines (e.g., 120 characters).
- Indent every line of code code as it is written. Consider using a tool to do so automatically.
- Insert braces/brackets/quotes/etc., in pairs. Type the closing pair immediately after the opener. Consider using an editor that does this automatically.

[RNBW]

@jonnin
It's the extra characters that make it clearer to me. Other than that, I only do it for myself. I keep a file with the pascal type structure but for others I change it back to C++ format. It's a simple exercise use Search and Replace.

@malibor
Yes the problems occur with the brackets (and with the pascal structure) when you copy and paste code from somewhere else. I find it easier to find the braces that have been copied over when I use the pascal structure. personal preference.

@mbozzi
The code in my editor is much tighter than it is when it is copied into the C++ forum. I use a two or three character indent. Like you I try to keep the line length to less than 80 characters, although sometimes it does go slightly over.

Overall, I don't think that we are too far apart. I just prefer to see the big blob caused by the pascal-like characters rather than the little blob caused by the brace. As I said, my eyesight is not getting any better as I get older (and I'm well past retiring age.

[lastchance]

@RNBW
Maybe you should try Python - then you will never need any braces around a block structure again.

Makes for some VERY careful indenting.

[zapshe]

At least you give a line for each bracket:

int main()
{
     //This is Life
}


int main() {

     //This is Chaos
}

[keskiverto]

If it helps, then why not. However, some case might get interesting:

int answerbegin42endBegin; // answer{42};
std::vector<int> testbegin3, 6, 8endbegin; // test{3, 6, 8};
auto it = test.begin(); // to replace or not to replace? 

[RNBW]

@lastchance
I've tried python. Don't like it very much. Might go back to it.

@zapshe
As much as possible I try to keep the braces on a separate line.


I woud make one point, because it won't be clear from my code shown above; I include begin and endBegin in the list of keywords, so they come up bold in the IDE. This really does make them stand out.

[dhayden]

Everybody has this own preference for expressing block structures. Many people are quite passionate about it.

I had an ah-ha moment many years ago. In retrospect it seems pretty obvious: the compiler may use braces, but humans understand the block structure from the indentation. From there it's a short step to "braces are a necessary evil (in C++ anyway). Express the block structure through indentation."

My own style is a combination of what I like, what my editor/indenter support, and what makes other parsing easier. For example, I put the opening brace of most functions on a line by itself. That way a brace in the first column is a really good indication of a new function. Otherwise I mostly cuddle the opening braces:

int main()
{ // start of function on its own line
    if (x ==y) {  // cuddle the brace
        f();
   } else if (z==k) {  // cuddle closing and opening brace
       g();
   }  // final closing brace on its own line Just Because.
}

I wouldn't use #defined tokens for the braces because they are likely to confuse anyone else reading your code, and you'll probably lose the ability of your editor to auto-indent the code.

[Ganado]

I have one complaint. If you're going to demonstrate your special #macros or other style modifications, at least be consistent with your new style.

	for (char ch; ((ch = getkeypress()) != '\n') && (ch != '\r');)
		if (isdigit(ch) || ((ch == '.') && (num.find('.') == string::npos)) || ((ch == '-') && num.empty()))
         begin
			num += ch;
			cout << ch;
		endBegin
		else
			if ((ch == '\b') && !num.empty())
			begin
				cout << ch << ' ' << ch;
				num.erase(prev(num.end()));
			endBegin
			else
				if (ch != '\b')
					cout << '\a';

This is not consistent. The begin on my line 3 isn't being matched with anything. And personally, I find the inconsistent use of braces hard to parse -- you use braces on the "if" part of the "if-else" but not the "else" part of it. I understand syntactically that you don't need the braces (or begin/endBegins) there, but I think the inconsistency between the logic branches makes it harder to read when combined with your modified syntax.

I also think too much indentation is happening here.

else
	if (ch != '\b')

can just be else if (ch != '\b')

else
	if ((ch == '\b') && !num.empty())

can just be
else if ((ch == '\b') && !num.empty())

[RNBW]

@Ganado

If you move on 3 lines you will find the matching endBegin. If it didn't have a matching endBegin the code wouldn't work.

The if does not have a curly brace, which is the one I have replaced.

In respect of the indentation, I generally like to keep the else on a separate line. It doesn't always happen, particularly if I copy and paste someone else's code.

I find the large indentations on cplusplus forum difficult because they spread out the code too much. As I said, it is much tighter on my IDE.

In respect of your comment about putting more code on one line, I go back to the old BASIC days (with line numbers) when memory was tight and the tendency was to put as much code as you could on one line. The advantage of more memory and better IDEs is that you can format it so it is more easily read.

Ultimately, one can argue all day about what is the best way to present the code and everybody is right and everybody is wrong. In some cases employers will wish the code to be presented in a particular way for consistency within the company, where there will be a lot of copying and pasting each others code.

Incidentally, the code I presented above is a modification of someone else's code, so i may not agree with the presentation of all of it. However, in an IDE it is easy to read and understand and it does work.

[MikeyBoy]

I find the large indentations on cplusplus forum difficult because they spread out the code too much. As I said, it is much tighter on my IDE.

That's probably because you've configured the editor in your IDE to insert TAB characters for indentation. That's fine, until you want to share your code with someone else - or publish it online - where those TAB characters may be interpreted very differently.

If you want your code to look as nice here as it does on your own IDE, reconfigure the editor to use actual space characters, rather than TABs.

[Ganado]

Yep I realize now that it was pretty much only 1 line out of place as far as the indentation goes, so not a big deal I see. Everything else comes down to just preference, I agree.

RNBW wrote:

The advantage of more memory and better IDEs is that you can format it so it is more easily read.

My qualm isn't about memory -- after all, in C++ the program will be compiled to the same thing either way. It's not about fitting as much as I can into one line, I don't like to do that either -- it's about logic flow, more levels of indentation is harder for humans to process or reason with.

if (a)
    foo();
else
    if (b)
        faa();
    else
        if (c)
            fob();

is, at least to me..., a lot less readable than

if (a)
    foo();
else if (b)
    faa();
else if (c)
    fob();

(In other words, code B shows its intention to the user more readily than code A)

Mikey Boy wrote:

reconfigure the editor to use actual space characters, rather than TABs.

Well that's a whole other argument, of tabs vs. spaces, let's not go down that path... :)

[MikeyBoy]

Well that's a whole other argument, of tabs vs. spaces, let's not go down that path... :)

I'm not making an argument. I'm advising the OP on something they can do if they want to resolve a specific issue.

[Ganado]

I see now.

[RNBW]

@MikeyBoy
I'd not realised that I'd configured the IDE to use tabs. I've now re-configured and done a check and you are absolutely correct. The code does format better in the cplusplus forum.

@Ganado
They are both acceptable methods and we'll have to agree to differ.

However, thank you everybody for contributing. It shows that people do care.