ide 设置编码

程序员的生活 (Programmer’s Life)

I recently wrote about how our coding style has evolved due to programming language evolution and the advancement of tools (e.g. IDE).

我最近写了一篇关于我们的编码风格如何随着编程语言的发展和工具(例如IDE)的发展而发展的文章。

Not everyone agrees that the way we code should be influenced by IDE. I can understand where that comes from and agree total reliance on some tools for the work is not ideal. Nonetheless, I can’t deny how the tools have influenced the way I code, just like Vim and Emac for some other people.

并非所有人都同意IDE会影响我们的编码方式。 我可以理解这是从哪里来的，并同意完全依靠某些工具进行工作并不理想。 尽管如此，我不能否认这些工具如何影响了我的编码方式，就像其他人使用的Vim和Emac一样。

开始时无需完美的代码组织 (No need for perfect code organization at the start)

I remember in those days before we start a project, meetings after meetings, documents after documents to discuss what’s the ideal code organization should be for a new project. Predicting how the project will evolve. All because we want to avoid future changes on the BASE of the code because changing them later will be difficult.

我记得在那些日子里，在我们开始一个项目之前，在会议之后开会，在文件之后讨论用于新项目的理想代码组织是什么。 预测项目将如何发展。 所有这些都是因为我们想避免以后在代码的BASE上进行更改，因为以后进行更改将很困难。

With IDE, we can easily move class around, rename them, and code will auto refactored all together. With little hassle for the developer to go search around and manually change them.

使用IDE，我们可以轻松地移动类，重命名它们，并且代码将一起自动重构。 开发人员可以轻松搜索并手动更改它们。

Example IDE feature that can change the file class name and everything can be changed together. 可以更改文件类名称的IDE示例功能，所有内容都可以一起更改。

With the ability to make changes easier, we can now not worry too much our initial structure is not ideal, the name is not good enough, etc, nor concern they are as futuristic prove since no one knows the future anyway. Changes later is no longer that daunting a task.

有了使更改变得更容易的能力，我们现在不必担心我们的初始结构不理想，名称不够好，等等，也不必担心它们就像是未来派的证明，因为没人知道未来。 以后的更改不再是一项艰巨的任务。

Having said this, I have to state that some due diligence is required for code to be reasonably structured with as meaningful names possible given to them. It’s never an excuse to neglect that. It is just that we can now avoid paranoid over the initial design to be put in place, so that we can have faster initial delivery.

话虽如此，我必须指出，为了合理地构造代码并为其赋予有意义的名称，需要进行一些尽职调查。 永远不要忽略这一点。 只是我们现在可以避免对要进行的初始设计产生偏执，从而可以更快地进行初始交付。

编码审查侧重于语义而不是语法 (Coding review focus on Semantic instead of Syntax)

When I first work in a software organization, we do code review in a room. We print the code back and read to find misalignment of code per the coding guide. I usually look for things like unused import, wrong { starting point, using spaces instead of tab, etc (not aligned indentation).

当我第一次在软件组织工作时，我们在一个房间中进行代码审查。 我们将代码打印回去，并按照编码指南进行阅读以发现代码未对准。 我通常会查找未使用的导入，错误的{起点，使用空格而不是制表符等(未对齐的缩进)之类的东西。

In another word, I’m focusing on the code structure more than the meaning of the code. Those are important back then as it helps make the code more “readable”.

换句话说，我更关注代码结构，而不是代码的含义。 那时候很重要，因为它有助于使代码更“可读”。

Today, I seldom focus on those areas anymore, but instead more on the business logic of the code (e.g. should a variable be nullable or not). The reason is simple, the tools have helped identify some basic code issues, and improved those structures for us.

今天，我很少再关注那些领域，而是更多地关注代码的业务逻辑(例如，变量是否可以为空)。 原因很简单，这些工具帮助识别了一些基本的代码问题，并为我们改进了这些结构。

e.g. the tool auto recommend the below variable can be private.

例如，自动推荐工具下面的变量可以是private 。

The likelihood of bad structure and naming convention can be easily corrected with the tool automation aid.

借助工具自动化工具可以轻松纠正结构和命名约定错误的可能性。

比简明代码更喜欢简明代码 (Prefer concise code than comprehensive code)

In the past, codes have to be as comprehensive as possible to ensure its maintainability. What comprehensive here means that by the first look at the code, it should have as much info as possible e.g.

过去，代码必须尽可能全面，以确保其可维护性。 这里所说的全面意味着首先看一下代码，它应该具有尽可能多的信息，例如

Coding comment should be available for complex or special cases

编码注释应适用于复杂或特殊情况

Prepended naming convention to show type e.g. mMemberVariable

前置命名约定以显示类型，例如mMemberVariable

Parameter naming e.g. download(url = URL, file = targetFile)

参数命名，例如download(url = URL, file = targetFile)

Those are the convention in the past, where code is reviewed in tools and not everyone in the team has the same IDE. But if everyone shares the same toolset, then we can focus on more concise coding instead of explicitly ceremonially write everything down.

这些都是过去的惯例，其中的代码是在工具中审查的，并非团队中的每个人都具有相同的IDE。 但是，如果每个人都共享相同的工具集，那么我们可以专注于更简洁的编码，而不必显式地将所有内容写下来。

E.g.

例如

不需要的显式代码注释 (Explicit code comment not as needed)

One can easily extract the git commit message and find the relevant commit message. Those will then reflect the change of the code much better. And best of all, if further changes are done, we no longer worried the comment is out of sync with the code.

可以轻松提取git commit消息并找到相关的提交消息。 这些将更好地反映代码的更改。 最重要的是，如果进行了进一步的更改，我们将不再担心注释与代码不同步。

不需要基于前缀的基于文本的命名约定 (Prepended text-based naming convention not as needed)

Text-based distinction of variable type, as syntax coloring is now available by default in all IDE source code viewer.

基于文本的变量类型区分，因为默认情况下所有IDE源代码查看器中都提供语法着色。

不需要明确的参数命名 (Explicitly argument naming not needed)

In the IDE, we can then just point over and get all the function type, so it clearly state the function parameter.

然后，在IDE中，我们只需指向并获得所有函数类型，即可清楚地声明函数参数。

I no longer need to code download(url = URL, file = targetFile)

我不再需要编码download(url = URL, file = targetFile)

Note: This is the assumption the entire team working on the code need to be using the name toolset (e.g. IDE) and have the ability to review them accordingly.

注意：这是假设整个团队中的代码团队都需要使用名称工具集(例如IDE)，并具有相应地对其进行审查的能力。

Anyway, I believe that concise coding is the future, as per the blog below.

无论如何，我相信简洁的编码是未来，如下面的博客所述。

边编码边学习 (Learning while coding)

Historically one has to study what are the APIs available so ensure we use the correct one. While this is still very much true, the IDE today has also helped my learning.

历史上必须研究可用的API，因此请确保我们使用正确的API。 尽管这仍然是非常正确的，但是今天的IDE也帮助了我的学习。

显示可用的API (Showing available APIs)

With the AutoComplete feature, I just need to type and search around, I will be able to find what API is available for that particular object.

使用“自动完成”功能，我只需要键入和搜索，就可以找到该特定对象可用的API。

学习新的API (Learning new APIs)

Not only I see what API is available, but I can also easily access the documentation of the API. Below is an example that provide all the description with diagram.

我不仅看到可用的API，而且还可以轻松访问API的文档。 下面是一个提供所有说明的示例。

Description of throttleFirst function. 节流阀第一功能的说明。

推荐更好的编码或API使用 (Recommendation of better coding or API usage)

Below is an example where I use filter { it is Int } which is better replace with filterIsInsance<Int>(). The IDE recommends it for me.

以下是我使用filter { it is Int }的示例，最好用filterIsInsance<Int>()代替。 IDE会为我推荐它。

Above are the few examples of how IDE has helped me vastly in my day to day programming job other than the basic Code, Compile and Debug that an IDE has been doing all the while. It enables us to make faster development, and also forego some of the older ways of concern but adopting new ways of development.

上面是一些示例，这些示例说明了IDE在日常工作中为我提供了巨大帮助，而IDE一直以来一直在进行基本的代码，编译和调试。 它使我们能够更快地发展，也放弃了一些旧的关注方式，但采用了新的发展方式。

翻译自: https://medium.com/@elye.project/how-ide-influences-my-coding-9130d1c18e34

ide 设置编码