RFC Coding Guidelines: Formatting Class Member Declarations | Haiku Project

Blog
8

Hello,

Here are my thoughts and opinion on this.

Going back to basics, the reason for the “table” style layout is to provide a clear overview. When you read through code, you can very easily find method names (they are all nicely aligned), which methods are virtual (looking at the modifier) or find a getter for some specific type of object (just looking at the return type).

Indeed, this ease of reading comes at the price of making it harder to write classes this way. Both for humans and for robots like haiku-format, since the rules are so complicated and almost into typesetting, rather than just text formatting.

It is also true that in modern C++, there are a lot more things to put in method declarations: attributes, override and final annotations, and so on.

So, can we find a way to still preserve some of the readability, while doing something simpler? For example, what about this?

class BHandler : public BArchivable
{
public:
	// The constructor doesn't have a return type and so it looks a bit strange. Is this a problem?
		BHandler(const char* name = NULL);
	virtual
		~BHandler();

	// BHandler guts.
	virtual void
		MessageReceived(BMessage* message);
	BLooper*
		Looper() const;
	const char*
		Name() const;

	// Fictional very long member function declaration
	// The parameters on next lines get indented one step further
	status_t
		Launch(const entry_ref* ref, const BMessage* initialMessage = NULL,
			team_id* _appTeam = NULL) const volatile noexcept;

// NOTE: compared to the example in the article, I have separates the private methods
// from the private members. I think this is not part of the changes being discussed here,
// in both the current and new style, these should be kept separated
private:
	friend inline int32
		_get_object_token_(const BHandler*);

private:
	// Do we want newlines also in the fields between the type and the name? or is it not needed?
	typedef BArchivable _inherited;
	friend class BLooper;

	int32 fToken;
	char* fName;
};

This proposal is a lot simpler: for method declarations in classes, the type goes on one line, and the method name goes in the next line, with one extra level of indentation.

It preserves the readability advantage of the previous style, but gives a lot more space for both the return type and the method name. And I think it is easier to implement.

It also solves another concert (raised in previous discussions by x512): now it is possible to display the code with the “wrong” tab size, and still get understandable results.

This is just one quick attempt at solving the problem. Maybe there are other, better ways.

2 Likes