Programming Styles

本文探讨了多种编程风格,包括Shotgun Programming、Cargo-cult programming等,分析了这些风格的特点及潜在问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Over the years I've met many developers and got to know many different programming styles. Here are some of the odd ones. Do you know someone like that?

Shotgun Programming

It is a programming style where the developer tries random shots at the code. "Well, this method call is failing.... I'll try changing this parameter from false to true!" Then of course it doesn't work and the developer goes: "Well, maybe I could just comment out the whole method call!" and so on. It can go on forever until it works by pure chance or the developer is rescued by a peer who points the correct solution.

A regular developer can go crazy in a few hours if he finds himself pairing with a shotgun programmer. It can drive you NUTS. Two shotgun programmers should never do pair programming together, because their destructive results are magnified when they work together.

Programming by accident

It is a mild form of Shotgun Programming, and it is surprising to see how common it is. I think this category encompasses the majority of developers worldwide by a wide margin. It happens when the developers doesn't really understand what he is doing, but things work. The dev codes some more, and the program still works. Since this is happening by accident, at some point something will break and the dev will have no idea on how to fix it. At this point, he usually has 2 courses of action: stop and understand what he did, in order to find the cause of the error, or, most likely, engage into Shotgun Programming to try to fix the problem.

Test Driven Development came to the rescue of the millions of programmers by accident. Now, you have an excuse to be program by accident: as long as the tests pass, you are good. Don't get me wrong, Test Driven Development is a Good Thing, and it limits the damage that can be caused by Programming by Accident.

Cargo-cult programming

The term comes from the Cargo Cults that appeared in many pacific islands during World War II. During the war, the US used the illands as bases and built airstrips for their cargo planes. The natives were amazed by the planes who brought all those goods and food. When the war was over, the planes disappeared, and the natives built their own air strips, with bamboo control towers, in the hope that if they did exactly like the white men did, the planes would return and bring back the beloved cargo.

Cargo cult programming is the practice of applying a popular solution just because everybody else is doing and it seems to work form them, but without understanding why it is being done that way. Lots of people engaged on it during the first years of J2EE by overusing EJBs and Entity Beans, for example.

Least effort programming

This style is very common specially among junior developers. One day you are assigned a task to fix a NullPointerException, so you just go to the line of code where the exception is generated and surrounds it with a if (reference != null).

It may very well work but you didn't solve the cause of the bug, you just hid it until it comes back to haunt you again. What you should have done is to go back and fix the problem that caused the reference to be null in the first place.

Design pattern driven programming

As the name says, it is the programming style where you use design patterns for EVERYTHING. Your code is full of Facade this, Observer that, Strategy whatever, Adapter, blah blah blah. It reaches a point where you have to dig real deep to find the code that does the actual job in the middle of the Design Pattern Tangle.

Surgical programmer

When working on a bug, the Surgical Programmer investigates the cause. And then the cause's cause. Then, he investigates the consequences of changing the code that is causing the other code to cause the other code to fail. Then he does a text search to find all usages of that class in the code, just in case. And for each match, he does another text search to find what uses the usage's usage. Then he writes unit tests for 30 different possible scenarios, even those that don't have anything to do with the bug he is fixing. In the end, full of confidence and with surgical precision, he fixes a typo.

In the meantime, the regular programmer fixed five other bugs.

Butcher programmer

It is the programmer that has an extreme itch to refactor everything he touches. It is the kind of programmer that, the night before shipping, when fixing a typo in an error message, changes 10 classes, refactors other 20, plus changes the build script and 5 deployment descriptors.
come from: http://www.codeinstructions.com/2008/10/styles-of-programming.html
内容概要:文章基于4A架构(业务架构、应用架构、数据架构、技术架构),对SAP的成本中心和利润中心进行了详细对比分析。业务架构上,成本中心是成本控制的责任单元,负责成本归集与控制,而利润中心是利润创造的独立实体,负责收入、成本和利润的核算。应用架构方面,两者都依托于SAP的CO模块,但功能有所区分,如成本中心侧重于成本要素归集和预算管理,利润中心则关注内部交易核算和获利能力分析。数据架构中,成本中心与利润中心存在多对一的关系,交易数据通过成本归集、分摊和利润计算流程联动。技术架构依赖SAP S/4HANA的内存计算和ABAP技术,支持实时核算与跨系统集成。总结来看,成本中心和利润中心在4A架构下相互关联,共同为企业提供精细化管理和决策支持。 适合人群:从事企业财务管理、成本控制或利润核算的专业人员,以及对SAP系统有一定了解的企业信息化管理人员。 使用场景及目标:①帮助企业理解成本中心和利润中心在4A架构下的运作机制;②指导企业在实施SAP系统时合理配置成本中心和利润中心,优化业务流程;③提升企业对成本和利润的精细化管理水平,支持业务决策。 其他说明:文章不仅阐述了理论概念,还提供了具体的应用场景和技术实现方式,有助于读者全面理解并应用于实际工作中。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值