Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save gjlmotea/71d3ecba4324dfb2333c890458f9fc54 to your computer and use it in GitHub Desktop.
Save gjlmotea/71d3ecba4324dfb2333c890458f9fc54 to your computer and use it in GitHub Desktop.
Possibility of Customized Personalized Coding Style across Collaborations.md

Re-imagining Personalized Code Formatting - A Vision for a Customizable Code Formatter

I feel that the current approach to code formatting seems too primitive. I want to spark everyone's imagination and discussion about personalized code formatting (which I'd like to call re-formatter). I wonder whether it's feasible or not. If it is, I hope someone will eventually take up the development of this idea.

About Coding Style

Code = the arrangement of logic as textual statements.

Everyone has their comfortable formatting style, just like reading an article. Text cannot be completely unformatted; it needs spaces and line breaks. This is aesthetics.

There may be a generally accepted most comfortable way of formatting worldwide. Although aesthetics may be somewhat similar among people, there are still subtle differences.

In fact, the same formatting method feels different for each person. The punctuation of the article is influenced by the author's usual breathing and speaking habits, which in turn affects the reader's pauses and coherence. Some can read 5 words at a time, while others can read 7 words.

Even choosing different fonts will affect these.

Everyone is different, and everyone has different aesthetics.

Existing Problems and Pain Points

It has always been a significant cost of collaboration in writing programs when people with different code styles work together.

The following are several aspects from personal and collaborative perspectives:

1. Learning a New Language

Whenever I learn a new language, I can't get used to it immediately (especially when writing two different languages simultaneously).

For example, different languages use different English words to express functions:

  • def
  • function
  • func
  • fun
  • f

Sometimes, I just want to write func. I don't want to type function so many times on the keyboard, and fun seems too short, while I don't want to write it as def.

I hope to use func in JavaScript, with it representing function. When an IDE or compiler sees func in the function's position, the code will automatically convert to function during execution.

a. I hope to be able to customize the built-in keywords of a programming language.

2. Why didn't the other party format code?

I saw two newcomers in the company working on the same project. A saw that the code written by B was not formatted at all, so A pressed the IDE shortcut key to format the whole page of code according to the IDE's style and felt that he had made a contribution.

Later, B saw the code written by A and also felt that A did not format it at all. The number of spaces didn't match, and the git comparison was all red differences. So B also pressed the shortcut key to format the whole page of code according to the IDE's style and also felt that he had made a contribution.

Both of them felt that the other didn't format the code after writing it. They went back and forth several times, and then the git record grew fat for nothing, resulting in only the tab and space settings of the two people's IDE.

3. Strict style is nice but seems to have no impact

Some projects have stricter requirements and demand good programming habits:

  • Adding a semicolon at the end of each line.
  • Adding public or private to each object member (even if the language doesn't require anything, and defaults to public).
  • Adding an extra line at the end of the page.

Every time I write code, I pay attention and follow the specifications. Having consistent code in the final project makes it look more appealing, but sometimes I wonder if all these extra words and effort are just for the sake of consistency in style.

4. Paragraph Spacing and Indentation

Everyone has a different comfort level when it comes to seeing dense or loose paragraphs. Some like to see a single line break between paragraphs, while others prefer two. Some prefer the number of spaces to depend on the length of the context.

I remember when I was in junior high, I used to write novels online without any line breaks, all densely packed. Then my classmates directly criticized me, "Hey, does hitting Enter cost you money at home?"

5. Word Count Per Line

How many characters should there be in a line of code?

  • Line break at 80 characters
  • Line break at 120 characters
  • No limit

I don't want the code to be too compressed, nor do I want to see it extend beyond the screen too much.

However, some people do have a Larger Screens!

b. I hope everyone can customize their own formatting, including line breaks for parameters and where to leave blank spaces, 
but it should only be visible on their own computer. It should not affect the repository. 
The code will be compressed locally (deleting all whitespace and unnecessary auxiliary words),
or it will be formatted according to the official standard version, or some other way, before Git comparisons or uploading to GitHub.

But this will lead to an issue, resulting in poor code readability on GitHub. 
I hope the customized formatting can also be applied when viewing remote repositories.

Additionally, because the phone screen is smaller, for the convenience of reading on the bus or subway, 
it would be great to have integration across devices, 
for example, displaying `func` on the computer and `fn` on the phone (resizing).

6. Different Naming Styles in Different Places

Each programming language usually has some conventions and recommended standards:

  • File names should be all lowercase.
  • Constants should be all uppercase.
  • Objects should be named using snake_case.
  • Function names should use CamelCase.
  • Internal function variables should use camelCase.
  • HTML tags and class names should be in lowercase with hyphens.
  • HTML IDs should use camelCase.
  • ...

I do know that the camelCase naming convention is promoted by the official standards, like helloWorldApiRequest.

But in some cases I wish I could mix things up because I find that this makes variable names more readable, just like when I look at actual English words, helloWorld_apiRequest.

Why does English even have to differentiate between lowercase and uppercase? Who came up with that genius idea? Semantic issues involving the symbols of the language itself, it's hard to blame anyone for that.

Actually, I have many similar questions. Why are special characters limited to these! @#$%^&*()=+... Why does the keyboard have only so many keys

c. I hope everyone can customize the presentation of variable names, freely adjust capitalization and underscores. 
It should only be visible on their own computer. 
I even hope to have variable names like "hello world(api request) - int64" 
freeing them from the constraints of spaces and special characters, not bound by past programming naming rules.

---

Below is a flight of fancy: 
Even with or without spaces, or without separators or underscores, 
as long as the semantics are correct, they represent the same entity. 

"hello_world (api request) - int64" and "hello world(apiRequest) int64" could be the same thing. 
I hope that one day, 
human can completely eliminate the barriers created by human language itself (in communication or writing).
For example, using multiple terms to describe the same entity or semantics, 
such as "referer"vs"referrer"、"溼姊"vs"濕姐"、"Hello"vs"Hello"、"磁碟"vs"軟盤"、"一二三"vs"甲乙丙"

7. Integration Across Different Programming Languages

This is the ultimate version, the integration across languages.

Some specifications and conventions in different languages:

  • Some HTML elements are self-closing tags, only having an opening tag and no closing tag.
  • In HTML, prefer double quotes; in JavaScript, prefer single quotes.
  • Upper camel case represents export; lower camel case represents local.
  • Strings use double quotes; characters use single quotes.
  • Add commas at the end of multiple lines, but in some languages, the last line should have a comma while others should not.
  • _hello_ vs __hello__
  • ...
  • ...
  • ...

Each programming language has its unique usage characteristics. If we have to remember each one, how can we deal with it?

Basic Usage of Programming Languages

Common language loops have several writing styles:

for (x;x;x) {
    ...
}
for x; x; x {
    ...
}
for x in range(x):
    ...

Is it possible to customize or interoperable these?

d. I hope that I can develop in any programming language using the language I am already familiar with or proficient in. 
Considering the support for data types and object-oriented programming, this might not be feasible in practice. 

What is more feasible is to achieve the mapping of programming languages through settings. 
It can convert the usage of if, for, function, 
etc., into a writing style similar to the familiar language,
achieving the basic logic of manipulating the program like arranging building blocks.

Vision for the Future

Code formatting tools are emerging endlessly, each with different configurations. Various formatting tools compete with each other, leading to a proliferation of coding conventions. This requires engineers to have more and more brain capacity.

Now, in November 2023, as soon as you enter a new company, the manager or team leader immediately asks you to install a certain formatter plugin and hands you a package of tool configuration files for code cleanup. They require you to use this setting every time you finish writing code to maintain the consistent style of the project code.

However, the semantics of the code should not be influenced by any formatting style. This seems to contradict the original intention of everyone should be comfortable with what they're looking at.

When is writing style something that needs to be discussed and decided by the whole team? Debating this is time-consuming, energy-consuming, and meaningless. After the discussion, someone will definitely not be willing to accept it. The opinions of new team members cannot be conveyed to the decision-makers who have already left.

Everyone has their preferences. Why can't I have a style that I find comfortable, which looks unique but doesn't affect friendly collaboration with others?

(If even the variable names and logical styles in the code can be consistent, that would be even better. But that's just wishful thinking and may not be feasible. If even the algorithm style can be consistent, that would be a terrifying thing.)

I hope that one day engineers can carry their own profile settings around freely. No matter where they go, no matter what project they see, everything feels comfortable because it's the style they are used to. Instead of focusing on the intricacies of these styles, they can focus on the logic and creativity in front of them.

So, I hope someone can develop a complete set of tools like this. I wonder if there are teams considering similar solutions now, or if there are any packages that can achieve this? Or what problems might arise from this in practice?

I have summarized my past experiences of writing code and put forward my own ideas, hoping that this hard brick will trigger everyone to think and discuss, and stir up better solutions.

@gjlmotea
Copy link
Author

gjlmotea commented Nov 8, 2023

Translated by ChatGPT.
Original article (in Chinese) here: https://ithelp.ithome.com.tw/questions/10214534

@romani
Copy link

romani commented Nov 8, 2023

I hope that one day engineers can carry their own profile settings around freely. No matter where they go, no matter what project they see, everything feels comfortable because it's the style they are used to.

This is point of misalignment of you and world. You think that you write code for yourself, but others consider your code as it it would be written for them. And this approach of non personal code is more robust and works better. For example, in checkstyle team, we have our own style, we have thousands of contributors, but looks like it was written by single and very experienced engineer who pay attention to any minor aspect of writing, as result next engineer who needs to extend code does not feel uncomfortable or disgusted by reading it.

We always craft workable solution by any means first, and end the end fix style issues.

So what we need is just autoformatter that will do boring task for you, if no automation you have to do this manually

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment