Code is for humans, not for computers.

Choose:

  AddElement(object, true, false);
  AddElement(object, true, true);
  AddElement(object, false, false);
  AddElement(object, false, true);

or

  AddElement(object, visible::on, deletable::off);
  AddElement(object, visible::on, deletable::on);
  AddElement(object, visible::off, deletable::off);
  AddElement(object, visible::off, deletable::on);

The latter is more readable, you can spot bugs easier, you don't need to remember which parameter was for visibility, and which was for indicating deletable. And it doesn't take much more to write this than a confusing boolean. It doesn't scale.

With a good IDE, the first one can be configured to look like the 2nd one.

But the 2nd one will always be more verbose, no matter if you need it or not.

So I'd choose the first one.

The first one will probably look confusing if you're looking at the repo through a web interface though. Or if you're looking at examples in a readme. I have personally never been limited by my "raw code writing speed", and if that was the case, I would look into touch typing/autocompletion before sacrificing readability.

Most source code will also be badly readable if you print it out ;)

So should we change our use of C++ to make it more GitHub-friendly? Or should we fix GitHub to properly work with the C++ source code that already exists?

I think it's not an issue of Github or not Github. Either you think of code as plain text first, or you think plain text is just another way to present it. I think of code as plain text first, and thus I like programming languages that don't need to be analyzed to be displayed properly. Other people may not think the same.

While I think parameter names at all call sites is the right solution, I don't think it's good enough to have this in the IDE alone. I still have to review code online that says `add(a, true)`, even if IntelliJ showed me `add(a, ignore_negatives:true)`.

The point is that this is a presentation issue. There is nothing wrong with the model. It would not be impossible for the reviewing software to analyze source code and display named parameters.

That would require every bit of software that presents this program not only to understand my programming langauge, but also to have enough context on the rest of the program to actually recognize the function and know what each parameter represents.

Not to mention, code is itself a presentation layer. Why would you put some presentation concerns in one layer (e.g. identifier names, indentation&styling), but others in another presentation layer?

this is true actually. every place we read code needs to also parse the code. it’s already happening today, that’s how you get syntax highlighting. the future of all code review in the browser is a more similar experience to coding in an ide. and eventually the browser will replace the ide (and you could say this is already happening too)

> every bit of software that presents this program not only to understand my programming language

You can either change your program to fit existing tools, or you can build smarter tools. I prefer the latter.

> code itself is a presentation layer

Not for the tool it isn't

edit: I think we can all agree that ideally we fix this in the language itself by adding optional named parameters

No matter how smart the tool is, unless it can see the definition of the function, it can't guess the parameter name. Code is often shared on mail, chat programs etc, requring me to send compilable code snippets to get nice presentation out of a blob of text would be significant overkill...

Your IDE could automatically add those annotations as rich text or embedded HTML when you copy the source code out from the IDE into the E-Mail.

Would it be rich text when I copy to WordPad and HTML when I copy to a web page? Would it also support Markdown and maybe wiki ML? Would IntelliJ know that when I'm pasting code to an Emacs buffer in java-mode it should paste plain text, but when I'm pasting to an Emacs buffer that is an email, it should instead add org-mode annotations?

Overall this concept of copy/pasting with context is nice, but it only works for applications that have a defined API between them, such as MS Office OLE objects. In all other cases, pasting plain text is better than any "smart" solution.

So your solution is to write code that is currently hard to read in the hope that someone will make a tool that presents it nicely in 10 years?

OTOH, programming for the human and not for the computer, included caring about presentation. I could say there's nothing right with the model either - a non-issue, personal preference.

... An older presentation issue is the tabs versus spaces flamewar. At least that one has burnt out. Maybe because of the rise of IDE's?

> ... An older presentation issue is the tabs versus spaces flamewar. At least that one has burnt out. Maybe because of the rise of IDE's?

My guess would be not IDEs but autoformatting tools, especially when communties like Go all follow one style.

> The point is that this is a presentation issue.

I think the point was that it shouldn't be.

> There is nothing wrong with the model

Seems to me there is.

Then apparently you need a code review tool which is as clever as the IDE.

That helps when you are writing the code. It's less helpful when you are modifying a function being called from all over the code base. Arguably smart enough refactoring tools will help, but smart enough compilers have been doing wonders for decades, too.