有意识的反模式行为 [英] Conscious antipattern behavior
问题描述
我一直想知道其他C ++程序员
在编码时没有做到，即使他们知道他们正在做的事情是...... baughty（顽皮）当然，下面的一些
项目也会出现在其他语言中。
人们偶然会不停地做这些事情，
但是我得到的是当我们制作它们的时候我们有意识地知道我们是坏的。这是一个更有趣的现象，因为我倾向于有意识地解释与语言作斗争。或者
有意识地不使用预期的语言
表示可以改善语言或
开发环境。
（当然，在C ++中，正确的方式是模糊的，因为
C / C ++具有广泛的表达能力，但有
是良好编码实践的非正式标准
我们都或多或少知道的b $ b。
示例：
- 重复代码通过复制/粘贴代替
制作子程序。
- 未能制作方法和其他东西''const''
它们应该是什么时候。
- 没有断言应该断言什么。
- 当它们合适时不使用模板。 />
- 尝试补丁而不是重构（无论如何只需要b / b
，然后
感到羞怯）。
- 传递给对象的函数引用
给函数提供太多信息，
只需要对象的几个成员。
- 制作& ;乱伦"调用而不是使用
信号/插槽/广播/听众或类似的
设计模式。
- 使用您自己的容器类而不是STL，
当STL是更好的选择。
- 使用#define宏代替模板函数。
- 使用布尔类型而不是枚举即使
你知道这种类型将很快超过
两种可能的状态。
- 让一个班级成长，直到它拥有数以万计的成员。
- 在参考时使用指针而不是引用
本来会更好。
- 将is-a放入在一个类中的成员而不是
创建一个新的子类，并让调用者以自己动态的RTTI形式查询这些成员。
- 使用错误代码返回或对象错误状态
而不是例外。
- 让班级成员公开，不应该是。
- 让一个函数长得很长只是因为
从技术上来说它实际上并没有被打破
进入子程序，因为他们都不会从其他任何地方调用
。
- 使用越来越多的预先指定的函数args
，以避免必须声明另一个类似名称的功能，或者相反 - 不使用
preassigned args，它们是有意义的。
- 使用add等名称制作方法和mul
而不是使用运算符重载。
- 命名，拼写，
接口策略不一致，等等。
- 声明比必要更多的全局对象。
- 在可共享的库中放置有意义的代码
进入应用程序端课程（或者只是让它b / b
坐在应用程序一边演变，同时告诉自己
你会把它分解出来有一天 ）。
- 使用char *而不是更友好的字符串类型。
- 使用两个成员变量来跟踪状态只有
一个逻辑成员（例如，一个bool和一个指针当
指针'为空时就足以表明
a假状态）。
- 按值而不是宏或枚举指定常量。
- 当size_t为
更好的类型（例如，你宣布一个基于零的计数器。
- 使用#define'而不是枚举。
- 使用外部枚举而不是类成员枚举。
- 使用结构而不是类（即使它变得非常明显，它应该是一个类）。
- 以一种方式解决一个典型的问题，然后在其他地方以不同的方式解决相同的问题因为
它是优越的，但没有回去升级
第一次实现的用法。
- 在某些地方使用malloc / free和operator new / delete
in其他，没有特别的原因。
显然上面的一些是在某些情况下的理性战术
决定，所以我不是
包括那些选择和背景的组合。
我很想知道什么是糟糕的选择
C ++程序员有意识地制造和为什么。那时候b $ b b更容易吗？更权宜之计？习惯的力量？
开发环境是否培养了这些习惯
（例如，一个有很好的复制/粘贴的编辑器可能
实际上是坏的） ？良好的编码是什么？
意志力或某些工具可以扭转局面吗？
极端或配对编程是否有帮助
打击这些趋势？是完美的纪律
甚至可取吗？
Ray
< blockquote> On Sun，2004年1月11日10:13:43 GMT，Ray Gardener
< ra ** @ daylongraphics.com>写道：
我一直想知道其他C ++程序员在编码时没有做什么，即使他们知道他们正在做什么是..顽皮（当然，下面的一些
项目也会出现在其他语言中）。
人们偶然会让这些漏掉，
但我会当我们制作它们的同时，我们有意识地知道我们是坏的。这是一个更有趣的现象，因为我倾向于有意识地解释与语言作斗争。或者有意识地不使用预期的语言
表示可以改进语言或
开发环境。
（当然，在C ++中） 正确的方式是模糊的，因为C / C ++具有广泛的表达能力，但是
是我们或多或少都知道的良好编码实践的非正式标准。
例如：
[snipped]
显然，在某些情况下，以上某些是合理的战术决策，所以我'不包括那些选择和背景的组合。
我很想知道C ++程序员有意识地做出什么样的糟糕选择以及为什么。那个时候更容易吗？更权宜之计？习惯的力量？
开发环境是否培养了这些习惯
（例如，一个复制/粘贴很好的编辑器可能实际上很糟糕）？良好的编码是否会影响意志力或某些工具是否会扭转潮流？
极端或配对编程是否有助于对抗这些趋势？是完美的纪律
甚至是可取的吗？
Ray
有些程序员根本不知道更好。然后有那些不想知道更好的人，因为他们已经离开了多年来他们的东西已经消失了b $ b并且没有人说过任何话。那么
是那些了解得更好的人，但是有这种根深蒂固的坏习惯，
试图完全遵守任何编程指南
使他们瘫痪，他们无法完成任何工作。然后
有些人想改变他们的方式，但是管理层不会因为各种原因而让他们放弃。
对于一些公司来说，内部软件开发只是必要的（或者至少是这样对待的）。
重构绝对没有预算，除非客户在门口大喊大叫。什么都没有？b $ b分配金钱，不能按工时付款来支付客户的b
。如果某些东西有效，或者似乎工作正常，那么它会以最少的测试结果发送到生产中（通常大多数测试
由开发人员完成，或者那里可能是一些集成测试
有这么有限的数据，没有错误出现之前
将这些东西发送给客户）。截止日期是完全不现实的
，如果开发人员尝试进行任何正确的设计，通常都不会遇到这种情况，而不是仅仅扯掉其他软件的零碎，使用第3个似乎做好工作的
派对组件不考虑以后
便携性或可扩展性等等。
在这样的环境中，通常没有代码审查。开发人员
认为他们是唯一需要维护他们自己的b $ b b代码的人，特别是如果该项目由于其他原因而导致生命周期很短
关注。由于没有任何东西可以重复使用，所以没有努力做出好的设计。在这种情况下，复制和粘贴通常似乎是实现代码重用的最快方式。
您的大部分示例都非常好。然而，模板和其他高级
语言功能直到最近才得到很多
编译器的充分支持，因此许多有经验的开发人员都避免使用
他们。因此，他们没有使用模板的经验，而且往往没有时间（或没有时间）参加其他课程，所以
他们可以学习如何使用它们。
只需2美分......
-
Bob Hairgrove
< a href =mailto：No ********** @ Home.com>没有********** @ Home.com
你的清单非常好。其中一个主要问题是
缺乏培训。
你将找不到很多关于这种面包和黄油的培训课程
问题。培训课程通常侧重于更高水平的
设计。
您可能会发现以下文章很有趣：
http://www.eventhelix.com/RealtimeMa...esign_tips.htm
http：// www。 eventhelix.com/RealtimeMa...ign_tips_2.htm
Sandeep
-
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - 系统架构设计案例工具
Ray-
好帖子。但是，如果你正在寻找某人投下第一块石头，你将不得不寻找其他地方。我们都不时削减一些角落。
-
Cy
http://home.rochester.rr.com/cyhome/
I''ve always wondered what other C++ programmers
fail to do while coding even though they know
what they''re doing is... naughty (and some of the
items below occur in other languages, of course).
People make these slip-ups all the time accidentally,
but what I''m getting at is when we make them while
we consciously _know_ that we''re being bad. This is
the more interesting phenomenon because I tend to
interpret consciously "fighting the language" or
consciously "not using the language as intended"
as an indication that the language or the
development environment could be improved.
(Granted, in C++ the "right way" is vague because
C/C++ has broad expressive capability, but there
are informal standards of good coding practice
that we all more or less know).
Examples:
- Duplicating code via copy/paste instead of
making subroutines.
- Failing to make methods and other things ''const''
when they should be.
- Failing to assert what should be asserted.
- Not using templates when they would be suitable.
- Trying patches instead of refactoring (only
to sooner or later refactor anyway, and then
feeling sheepish about it).
- Passing to functions references to objects
that give too much info to the function,
when it only needs a few members of the object.
- Making "incestuous" calls instead of using
signal/slots/broadcasters/listeners or similar
design patterns.
- Using your own container classes instead of STL,
when STL would have been the better choice.
- Using #define macros instead of template functions.
- Using boolean types instead of enums even though
you know that the type will soon grow beyond
two possible states.
- Letting a class grow until it has a zillion members.
- Using pointers instead of references when refs
would have been better.
- Putting "is-a" members inside a class instead of
making a new subclass, and having callers query
those members in a roll-your-own form of RTTI.
- Using error code returns or object error states
instead of exceptions.
- Letting class members be public that shouldn''t be.
- Letting a function grow really long only because
technically it doesn''t actually have to be broken
down into subroutines because none of them would
be called from anywhere else anyway.
- Using more and more preassigned function args
to avoid having to declare another function of
a similar name, or the reverse -- not using
preassigned args where they make sense.
- Making methods with names like "add" and "mul"
instead of using operator overloading.
- Being inconsistent in naming, spelling,
interface strategies, etc.
- Declaring more global objects than necessary.
- Placing code that makes sense in a shareable library
into application-side classes (or just letting it
sit and evolve on the app side while telling yourself
that you''ll factor it out "someday").
- Using char* instead of a more Unicode-friendly string type.
- Using two member vars to track a state of only
one logical member (e.g., a bool and a pointer when
the pointer''s being null will suffice to indicate
a false state).
- Specifying constants by value instead of by macro or enum.
- Using int instead of size_t when size_t is the
better type (e.g., you''re declaring a zero-based counter).
- Using #define''s instead of enums.
- Using external enums instead of class member enums.
- Using a struct instead of a class (even when it becomes
painfully obvious that it should be a class).
- Solving a typical problem one way, then the same
problem a different way somewhere else because
it is superior, but failing to go back and upgrade
the usages of the first implementation.
- Using malloc/free in some places and operator new/delete
in others, for no particular reason.
Obviously some of the above are rational tactical
decisions under certain situations, so I''m not
including those combinations of choice and context.
I''m interested in finding out what poor choices
C++ programmers consciously make and why. Was it
easier at the time? More expedient? Force of habit?
Does the dev environment foster those habits
(e.g., an editor with great copy/paste might
actually be bad)? Is good coding a matter of
willpower or do certain tools turn the tide?
Does extreme or paired-up programming help
combat these tendencies? Is perfect discipline
even desirable?
Ray
On Sun, 11 Jan 2004 10:13:43 GMT, "Ray Gardener"
<ra**@daylongraphics.com> wrote:
I''ve always wondered what other C++ programmers
fail to do while coding even though they know
what they''re doing is... naughty (and some of the
items below occur in other languages, of course).
People make these slip-ups all the time accidentally,
but what I''m getting at is when we make them while
we consciously _know_ that we''re being bad. This is
the more interesting phenomenon because I tend to
interpret consciously "fighting the language" or
consciously "not using the language as intended"
as an indication that the language or the
development environment could be improved.
(Granted, in C++ the "right way" is vague because
C/C++ has broad expressive capability, but there
are informal standards of good coding practice
that we all more or less know).
Examples:
[snipped]
Obviously some of the above are rational tactical
decisions under certain situations, so I''m not
including those combinations of choice and context.
I''m interested in finding out what poor choices
C++ programmers consciously make and why. Was it
easier at the time? More expedient? Force of habit?
Does the dev environment foster those habits
(e.g., an editor with great copy/paste might
actually be bad)? Is good coding a matter of
willpower or do certain tools turn the tide?
Does extreme or paired-up programming help
combat these tendencies? Is perfect discipline
even desirable?
Ray
Some programmers just plain don''t know any better. Then there are
those who don''t want to know any better because they have gotten away
with their stuff for years and nobody ever said anything. Then there
are those who know better, but have such ingrained bad habits that the
attempt to adhere to any kind of programming guidelines totally
paralyzes them and they can''t get any work done as a result. Then
there are those who would like to change their ways, but management
won''t let them for various reasons.
For some companies, in-house software development is only a necessary
evil (or at least treated as such). There is absolutely no budget for
refactoring unless the customer is at the door screaming. Nothing is
allocated money-wise that cannot be billed on a basis of man-hours to
a paying customer. If something works, or seems to work OK, it is sent
into production with a minimum of testing (usually most of the testing
is done by the developer, or there might be some integration tests
with such a limited amount of data that no bugs ever show up before
sending the thing to the customers). Deadlines are totally unrealistic
and are usually not met if the developers try to do any proper design
instead of just ripping out bits and pieces of other software, use 3rd
party components which seem to "do the job" without regard to later
portability or extensibility, etc. etc.
In such an environment, there is very often no code review. Developers
think they are the only ones who will ever have to maintain their own
code, especially if the project has a short life cycle due to other
concerns. Since nothing gets reused, no effort is made to make a good
design. Under these circumstances, copying and pasting often seems to
be the quickest way of implementing "code reuse".
Most of your examples are very good ones. Templates and other advanced
language features, however, were not supported adequately by a lot of
compilers until just recently, so lots of experienced developers avoid
them. As a result, they have no experience using templates and often
don''t have the time (or aren''t given time) for additional courses so
they can learn how to use them.
Just my 2 cents ...
--
Bob Hairgrove
No**********@Home.com
Your list is very good. One of the main problems is
lack of training.
You will not find many training courses on such bread-and-butter
issues. Training sessions often focus on much higher level of
design.
You might find the following articles interesting:
http://www.eventhelix.com/RealtimeMa...esign_tips.htm
http://www.eventhelix.com/RealtimeMa...ign_tips_2.htm
Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool
Ray-
Nice post. But if you''re looking for someone to cast the first stone you''ll
have to look elsewhere. We all have cut a few corners from time to time.
--
Cy
http://home.rochester.rr.com/cyhome/
这篇关于有意识的反模式行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
