在新工作中继承申请
在新工作中继承应用程序时，您倾向于坚持原来的开发人员编码实践还是开始应用自己的编码实践？
我在一家没有任何指导方针的小商店工作，总是想知道这里的规则是什么。 有些应用程序写得很好，但不遵循我使用的标准（变量名称等......），我不想“弄脏”它们。 我发现我自己花了一点额外的时间来保持一致。
其他人写得非常糟糕，看起来开发人员每次击键都改变了主意......
额外的想法
当我开始自己的项目时呢？ 所以现在我引入了一个新的编码标准：
- 好的代码 - 但不是我的风格
- 不好的代码，实践不好且缺乏标准
- 我自己的标准
When inheriting applications at a new job do you tend to stick to the original developers coding practices or do you start applying your own?
I work in a small shop with no guidelines and always wondered what the rule was here. Some applications are written very well but do not follow the standards I use (variable names etc...) and I do not want to "dirty" them up. I find my self taking a little extra time being consistent.
Others are written very poorly and it looks like the developer was changing his mind every keystroke...
ADDITIONAL THOUGHT
What about when I start my own projects? So now I have introduced a new coding standard to the mix:
- The good code - but not my style
- The bad code with bad practices and lack of standards
- My own standards
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
我认为这取决于您所说的“编码实践”的含义。 如果您指的是代码格式和命名约定之类的东西以及我个人认为“美观”的东西，那么请坚持使用已有的东西。 如果您首先指的是编码最佳实践和正确编写代码之类的事情，那么如果可能的话，请返回并修复问题，但至少让您的新代码遵循最佳实践。
I think it depends on what you mean by "coding practices". If you mean things like code formatting and naming conventions and things that I would personally consider "cosmetic", then stick with whats already there. If you mean things like coding best prcatices and writing code correctly in the first place, then go back and fix the problems if possible, but at the very least make your new code follow best practices.
鉴于我继承的大多数应用程序都是由“牛仔编码员”编写的，他们甚至没有应用最基本的编码实践，我的观点有点偏见。
我说，如果没有编码标准，或者存在的编码标准明显错误和/或愚蠢（例如“所有变量的长度不得超过 4 个字符”、“每个数据库列都是 varchar(255) null”等） .)。 显然，如果你有一个团队，那么你需要就实施哪些实践达成一致，但如果你是一个独立开发者，那么你有自由统治权，在我看来，你应该为混乱引入秩序。
Given that most of the applications I've inherited have been hacked together by "cowboy coders" who didn't apply even the most basic of coding practices, my opinion is a little biased.
I say introduce coding standards if there are none or the ones that exist are blatantly wrong and/or stupid (e.g. "All variables must be no more than 4 characters in length", "Every database column is varchar(255) null", etc.). Obviously if you have a team then you'll need to come to an agreement as to what practices to implement, but if you're a solo dev then you have free reign and IMO you should introduce order to the chaos.
组合通常优于继承
:-P
composition is often preferred over inheritance
:-P
如果只有你一个人，那就去吧。 如果是一个团队，特别是如果任何原始开发人员仍然存在（或可能被要求提供咨询），请尽可能保持现有的风格和实践。 不要跟着他们走进老鼠洞——如果你认为他们做了一些愚蠢的事情，就改变它，但如果这只是一种风格上的事情，那就尽可能保持他们的风格。
在我从事过的几份工作中，除了“如果要更改现有文件/类，请使用现有样式，即使是新代码”之外，我们对编码风格没有任何规则。
If it's just you, go for it. If it's a team, especially if any of the original developers are still around (or likely to be called in for consulting), keep with the existing style and practices as much as you can. Don't follow them down a rat hole - if you think they're doing something stupid, change it, but if it's just a stylistic thing, keep to their style as much as you can.
On several jobs I've been on, we had no rule on coding style other than "if you're making changes to an existing file/class, use the existing style, even for new code."
如果有的话，我会遵守公司标准。
如果没有任何变化并且变化很小，我会采用使用的编码风格。
如果需要进行较大的更改并且我不喜欢编码器的风格，我将使用我自己的风格。
如果现有代码不好，我也会更改它。
I follow company standards if there are any.
If there aren't any and the changes are small, I adopt to the used style of coding.
If there are larger changes to be made and I don't like the coder's style, I will use my own.
And if the existing code is bad I will change that too.
您是否有更好的机会使用标准样式更新现有代码？ 可能不会。 当您对代码不熟悉时，您将有最好的机会花一些额外的时间来进行非新功能和非错误修复的更改。 缺乏标准可能会令人沮丧，但与第一次继承代码时相比，您不太可能有更好的标准化机会。
Will you ever have a better opportunity to update existing code with a standard style? Probably not. When you are new to the code you are going to have the best chance of taking some extra time to make non-new-feature and non-bug-fix changes. The lack of standards may be discouraging but you are unlikely to have a better chance to standardize than when you first inherit the code.
听起来我们正在谈论没有官方风格指南/最佳实践的情况。 在这种情况下，正如肖恩所说，我会带头建立一些。 但是......如果可能的话，选择一个现有的、广泛使用的标准。 它更有可能被接受，所有的论据都已完成，并且开箱即用的工具支持（编辑器、代码审查工具等）的可能性大大增加。
让其他人采用它通常是自下而上的最佳方式 - 根据新标准编写新代码，向其他人提及您已经这样做，寻求反馈。 比尝试提前获得批准和支持要容易得多。
在现有的、丑陋的项目中，避免对现有模块进行大规模更改。 一方面，如果文件突然重新缩进，差异和版本控制将变得非常混乱。
如果您正在处理的块太糟糕到无法读取，我会进行初步签入只是以重新格式化它； 接下来进行实际的代码更改。
It sounds like we're talking about a situation with no official style guides / best practices. In that case, as Sean said, I'd take the lead on establishing some. But... if at all possible, pick an existing, widely-used standard. It's more likely to be accepted, all the arguments are done with, and the odds of out-of-the-box tool support (editors, code review tools, etc.) greatly increase.
Getting others to adopt it will often work best from the bottom up -- write new code to the new standards, mention to others that you've done so, ask for feedback. Much easier than trying to get approval and buy-in in advance.
Within the existing, ugly project, avoid wholesale changes to existing modules. For one thing, diffs and version control will get quite confusing if a file is suddenly reindented.
If the chunk you're working on is so bad as to be unreadable, I'd do an initial checkin just to reformat it; follow that up with actual code changes.
我会对代码应用相同的重构标准，就像它确实符合我的风格标准一样。 也就是说，我会忽略风格并继续我的工作。
如果遵循代码中的风格不是非常困难 - 关于命名约定，我会继续将它们用于新代码。
然而，我不会费心去遵循诸如“不应使用制表符”、“每行应缩进 2 个空格”等内容。有很多编辑器，您可以在需要时“美化”代码这几天。
G-曼
I would apply the same refactoring standards to the code as I would if it DID match my style standards. That is, I'd ignore the style and just go on about my business.
If it's not terribly difficult to follow the style that is in the code - with regards to naming conventions, I'd go ahead and use those for new code.
However, I wouldn't bother trying to follow stuff like 'tabs should not be used', 'every line should be indented 2 spaces', etc. There are plenty of editors out there where you can 'pretty' the code whenever you need it these days.
G-Man
我认为这很大程度上取决于具体情况。
I think it depends highly on the specific case.
简短的回答是：“这取决于情况。” 以下是我认为在决定是否保留旧样式时重要的几个因素：
1）更改的范围。 如果应用程序接近完全重写，那么如果您认为新标准适合您，那么采用新标准可能更有意义。
2）未来变化的可能性。 这会一再改变吗？ 如果是这样，那么尽早花一些时间最终可能是值得的。 这确实需要一些判断和预测未来，但在某些情况下可能很容易看出某些相当复杂的系统会一遍又一遍地发生变化。
3) 与完全自行开发的应用程序相比，有多少代码是对第 3 方代码库进行定制的，例如，公司针对其业务流程对 Oracle 产品进行的特定定制。 这里的影响是，当发布新版本并请求升级时，由于定制程度如此之高，可能会对出现的问题造成多大的痛苦。
当开始自己的项目时，请采用您所知道的最佳标准。
Short answer is, "It depends." Here are a few factors that I'd consider important in determining whether to keep the old style or not:
1) Scope of changes. If it is close to a total re-write of the application, then it may make more sense to put in a new standard if you have one that you feel works well for you.
2) Likelihood of future changes. Will this be changed over and over again? If so, then taking some time early on may well be worth it in the end. This does require a bit of judgement and predicting the future, but it may be easy in some cases to see that there will be changes over and over again for some systems that are fairly complex.
3) How much of the code is a customization on a 3rd party codebase, e.g. a company's specific customizations of Oracle products for their business processes, compared to a completely home grown application. The impact here is that when new versions are relased and an upgrade is requested, how much pain may there be on what breaks since it was customized so much.
When starting your own projects, put in the best standard that you know.
如果我继承的代码显然从未被重构过，我会以此为契机强加一些我自己的结构。
如果人们期望我对向代码添加功能进行时间和成本估计，我需要非常熟悉它，并确保它符合我的标准。
如果代码已经写得很好，那就太好了，我不会乱搞。 但根据我的经验，这种情况并不经常发生。
If I inherit code that has obviously never been refactored, I would take that as an opportunity to impose some of my own structure.
If people expect me to make time and cost estimates for adding functionality to the code, I'll need to be intimately familiar it, and make sure it lives up to my standards.
If the code is already well-written, that would be a blessing that I would not mess with. But in my experience, this hasn't happened very often.
如果代码中有明显的标准，您应该遵守它们。 如果没有，请开始介绍您自己的。
If there are standards evident in the code, you should stick to them. If there aren't, start introducing your own.
如果有多个开发人员在同一模块上工作，请不要更改样式。
如果您在不久的将来将其交给另一个开发人员（这个角色是临时的），请不要更改样式。
如果您对该模块拥有完全、排他、永久的所有权，请更改它，但请遵循以下规则：
一次更改一次。
立即根据您的喜好修复所有缩进，然后提交该更改。
立即根据您的喜好修复所有支架位置，并提交更改。
立即根据您的喜好修复所有其他格式，然后提交更改。
立即根据您的喜好修复所有命名，然后提交更改。
不要花太多时间。
如果花费的时间超过一两个小时，那就减少时间。
使提交描述清晰。
这样您在分析更改历史记录时可以快速忽略这些更改。
使用自动化工具
确保结果一致且完整，这样您就不必再次搞乱它。
运行测试
仅仅因为您的更改不应该影响行为并不意味着它们不会。 （三重否定，哎呀！）
确保每个人都知道你在做什么
有人可能有一个他们想要立即提交的更改，并且与您的更改合并会很痛苦。 另外，您也不希望任何人感到惊讶并在您这样做之前告诉您的老板。
不要再这样做
这是一次性的事情。
If there are multiple developers who work on the same module, don't change the style.
If you will hand it off to another developer in the near future (this role is temporary), don't change the style.
If you are taking complete, exclusive, permanent ownership of the module, change it, but follow these rules:
One change at a time.
Fix all indentation to your liking at once, and commit that change.
Fix all brace placement to your liking at once, and commit that change.
Fix all other formatting to your liking at once, and commit that change.
Fix all naming to your liking at once, and commit that change.
Don't spend a lot of time on it.
If it takes more than an hour or two, then cut back.
Make the commit description clear.
So you can quickly ignore these changes when analyzing change history.
Use automated tools
to make sure the result is consistent and complete, so you don't have to mess with it again.
Run your tests
Just because your changes shouldn't affect behavior doesn't mean they won't. (Triple negative, ouch!)
Make sure everyone knows what you're doing
Someone might have a change hanging around that they want to commit now, and it'll be painful to merge with your changes. Also, you don't want anyone to get surprised and go tell your boss before you do.
Don't do it again
This is a one-time thing.
发布遵循最佳实践的风格指南，并围绕遵循它建立共识。 根据需要重构旧代码以维护它。
Publish a style guide that follows best practices, and build consensus around following it. Refactor old code as you need to maintain it.
我和你在同一条船上。 孤独的开发者从上一个人那里继承了一些应用程序。 为了保持一致性，我
一直坚持他对现有项目的标准，并使用我自己对新东西的偏好。
I'm in the same boat as you. Lone developer who inherited some apps from the last guy. I
I've been sticking to what appear to be his standards for existing projects for consistency, and using my own preferences for new stuff.
我注意到大多数人认为无论他们之前的人都不知道如何编写代码。 那么无论他们之后的人都会有同样的想法。 有些事情是常识，但大多数事情只是个人喜好。
对于主要问题，即使用注释与不使用注释，更新代码可能会使其更容易使用，并且其他人也更容易使用。 即便如此，您的时间可能最好花在更新遇到的代码上，而不是着手一个庞大的项目来重构所有内容（在此过程中引入新问题）。
对于诸如缩进、行间距、变量名称、单行 if 与多行 if 等问题，现实情况是您的编码风格可能和您想象的一样糟糕。
I've noticed that most people think whoever came before them had no idea how to write code. Then whoever comes after them thinks the same thing. Some things are common sense, but most things are just personal preference.
For major problems, i.e. using comments v.s. not using comments, updating the code will probably make it easier to work with, and easier for anyone else to work with. Even then, your time is probably best-spent updating the code as you come across it, instead of embarking on a huge project to refactor everything (introducing new problems in the process).
For things like indentation, line spacing, variable names, one-line ifs v.s. multi-line ifs, the reality is that your coding style is likely just as bad as you think theirs is.