其他人对这段代码做了什么？ [英] What do other's make of this code?

问题描述

这是我一直在关注的东西，因为它是KDevelop新应用程序向导中当前损坏的部分的核心。我不抱怨

它被打破了，这是一张CVS图片。这样的事情发生了整个

子系统正在经历根本性的变化。我真的不想说

我对代码的看法。这会影响其他人的意见，我真的想知道其他人如何看待这些事情，

而不影响他们的意见。我会说这么多：我在文件/类的整体结构中看起来是

，还有一些细节如

作为for（）循环。


这是LXR：
http://lxr.kde.org/source/kdevelop/p...appwizarddlg.h
http://lxr.kde.org/source//kdevelop/...pwizarddlg.cpp


这是API Doxygenese，我觉得眼睛更容易：

http://developer.kde.org/documentati...ardDialog.html


特别是源文件演示文稿。

http://developer.kde.org/documentati...8h-source.html
http://developer.kde.org/documentati...pp-source .html


我的

介意中有一些结构性问题值得怀疑。与此同时，代码确实（确实）做了它应该做的事情，其中​​

非常重要。


-

STH

哈顿定律：只有一个不可侵犯的法律

KDevelop： http://www.kdevelop.org SuSE： http://www.suse.com

Mozilla： http://www.mozilla.org

This is something I''ve been looking at because it is central to a currently
broken part of the KDevelop new application wizard. I''m not complaining
about it being broken, It''s a CVS images. Such things happen. The whole
subsystem is going through radical changes. I don''t really want to say
what I think of the code just yet. That would influence the opinions of
others, and I really want to know how other people view these things,
without my influence on their opinions. I will say this much: I''m looking
at the overall structure of the files/class, and also at a few details such
as the for() loops.

This is the LXR:
http://lxr.kde.org/source/kdevelop/p...appwizarddlg.h
http://lxr.kde.org/source//kdevelop/...pwizarddlg.cpp

This is the API Doxygenese, which I find a bit easier on the eyes:

http://developer.kde.org/documentati...ardDialog.html

Particularly the source file presentation.

http://developer.kde.org/documentati...8h-source.html
http://developer.kde.org/documentati...pp-source.html

There are a couple structural issues which stand out as questionable in my
mind. At the same time, The code does(did) do what it''s supposed to, which
is very important.

--
STH
Hatton''s Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

推荐答案

Steven T. Hatton写道：

http：/ /developer.kde.org/documentati...8h-source.html

Steven T. Hatton wrote:

http://developer.kde.org/documentati...8h-source.html

http：/ /developer.kde.org/documentati...pp-source.html
在我的脑海里，有一些结构性问题值得怀疑。与此同时，代码确实（确实）做了它应该做的事情，
这非常重要。

http://developer.kde.org/documentati...pp-source.html
There are a couple structural issues which stand out as questionable in my
mind. At the same time, The code does(did) do what it''s supposed to,
which is very important.

由于反响​​热烈，我已经决定详细说明我在这段代码中看到的
。在我这样做之前，请允许我解释一下我提出此代码的原因。代码表示真实应用程序中的实际代码，实际上是
。这是非常重要的，而且质量可能比较好。除此之外，我正在试图确定代码是什么样的'常规'，即这是一种''正常''方法，

''正常''成语？我也对其他人对这些

惯例（或未发生的情况）的看法感兴趣。


我会列出一些观察结果。


1）使用m_member_field是我经常看到的。我不喜欢b $ b特别喜欢它。对于大多数b
的程序员来说，我的替代方案可能没有吸引力，而且我很可能不得不投降到大多数人的b / b
。 ''m_''的意图是将变量区分为成员

字段。我的回答是，这是/ this-> /的用途。当我提到当前班级的成员时，我确实倾向于使用

this-> member_field，尽管为了符合要求我为了实践而离开了练习。


2）使用/ struct / s让我有点不舒服。有一个

的学校认为在/ b
中出现的/ struct / s的性质应该被视为一个访问私有成员的类

通过set和get方法。这是一种非常JavaBeans的方法，并且在一些领域中，它可能是一个合理的指导方针。


从我在TC中读到的内容++ PL（SE），Stroustrup可能会肯定我提供的样本中使用的

方法。从我的角度来看，

/ struct / s确实为程序添加了结构，而没有引入很多由单行组成的超额代码。使用/ struct / s

作为具有私有或受保护成员的类的替代方案可能比杂乱和混淆代码更多。

。 OTOH，它需要（IMO），

程序员坚持礼貌，只能访问

/ struct / s的成员，就好像他们是私人类成员一样。


3）这是我在AppWizardDialog课上遇到的最大问题：

a Favo（u）礼仪课渴望独立。我通过创建一个单独的收藏夹（原文如此）

类来尝试重构代码，我付出了一点努力

。在这一点上，这并不是直截了当的。在当前的

情况下，AppWizardDialog似乎不必要地使用代码来使用

来管理收藏夹列表。如果程序员

正确拼写* _favorites_ *，那会有所帮助！ ;-)


-

STH

哈顿定律：只有一个不可侵犯的法律

KDevelop： http://www.kdevelop.org SuSE： http://www.suse.com

Mozilla：< a rel =nofollowhref =http://www.mozilla.orgtarget =_ blank> http://www.mozilla.org

Due to the overwhelming response, I''ve decided to elaborate a bit on what I
see in this code. Before I do that, please allow me to explain a bit more
my reasons for presenting this code. The code represents real live code,
in a real application. It is non-trivial, and probably of comparatively
good quality. Among other things, I''m trying to determine how
''conventional'' the code is, i.e., is this a ''normal'' approach, with
''normal'' idioms? I''m also interested in what others think about these
conventions (or unconventions, as the case may be).

I''ll just list some observations.

1) the use of m_member_field is something I''ve seen a lot. I don''t
particularly like it. My alternative is probably unattractive to most
programmers, and I will most likely have to capitulate to the majority on
this. The intent of the ''m_'' is to distinguish the variable as a member
field. My response is, that is what /this->/ is for. I do tend to use
this->member_field when referring to members of the current class, though I
am moving away from the practice for the sake of conformity.

2) The use of /struct/s makes me a bit uncomfortable. There is a school of
thought that says anything of the nature of the /struct/s that appear in
this class should be treated as a class with private members accessed
through set and get methods. That is a very JavaBeans approach, and in
some areas, its probably a reasonable guideline to adhere to.

From what I''ve read in TC++PL(SE), Stroustrup would probably affirm the
approach used in the sample I''ve provided. From my perspective,
the /struct/s do add structure to the program without introducing a lot of
excess code consisting of one-liners. The alternative using the /struct/s
as classes with private or protected members would probably do little more
than clutter and obfuscate the code. OTOH, it requires (IMO), that the
programmer adhere to good manners, and only access the members of
the /struct/s as if they were private class members.

3) This is the biggest issue I have with the AppWizardDialog class: there is
a Favo(u)rites class yearning to stand on its own. I put a little effort
into trying to refactor the code by creating a separate Favourites(sic)
class. It is not straight forward at this point to do so. In the current
situation, the AppWizardDialog seems unnecessarily cluttered with code used
to manage the favourites list. And it would have helped if the programmer
had spelled *_favorites_* correctly! ;-)

--
STH
Hatton''s Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

....（我的评论是穿插的）...


星期五，2004年5月28日05:34:10 -0400，Steven T. Hatton

< su ****** @ setidava.kushan.aa>写道：

....(my comments are interspersed)...

On Fri, 28 May 2004 05:34:10 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote:

Steven T. Hatton写道：

http://developer.kde.org/documentati...8h-source.html

Steven T. Hatton wrote:

http://developer.kde.org/documentati...8h-source.html

http：/ /developer.kde.org/documentati...pp-source.html

有几个结构性问题在我的脑海中显得有些疑问。与此同时，代码确实（确实）做了它应该做的事情，
这非常重要。

There are a couple structural issues which stand out as questionable in my
mind. At the same time, The code does(did) do what it''s supposed to,
which is very important.

由于反应热烈，我''我决定详细说明我在这段代码中看到的内容。在我这样做之前，请允许我解释一下我提出此代码的原因。代码表示真实应用程序中的真实实时代码。这是非常重要的，可能质量相对较好。除此之外，我正在试图确定代码是如何传统的，即这是一种正常的方法，具有正常的习语吗？我也对其他人对这些约定的看法感兴趣（或者不同意，或视情况而定）。

Due to the overwhelming response, I''ve decided to elaborate a bit on what I
see in this code. Before I do that, please allow me to explain a bit more
my reasons for presenting this code. The code represents real live code,
in a real application. It is non-trivial, and probably of comparatively
good quality. Among other things, I''m trying to determine how
''conventional'' the code is, i.e., is this a ''normal'' approach, with
''normal'' idioms? I''m also interested in what others think about these
conventions (or unconventions, as the case may be).

除了Qt成语之外，我以前从未工作过，我发现代码结构高，易于理解。 HTML

文档很可爱，包含所有链接。您可以通过点击符号或名称在任何标题中找到几乎任何
。


但是，还有其他问题。没有太多的时间来投资这个代码评论，这里只是我立即注意到的一个项目：


我强烈建议不要使用文字硬编码值，

用常量替换。在整个代码中都有字符串文字，但也有数字文字 - 例如在执行

AppWizardDialog :: licenseChanged（）函数时切换

语句。像这样的代码是一个

的噩梦，例如，如果需要将文本翻译成另一种语言，则需要将文本翻译成

我我只列出一些观察结果。

1）使用m_member_field是我经常看到的。我不是特别喜欢它。对于大多数程序员来说，我的选择可能没什么吸引力，而且我很可能不得不向大多数人投降。 ''m_''的意图是将变量区分为成员
字段。我的回答是，这是/ this-> /的用途。在提到当前班级的成员时，我确实倾向于使用
this-> member_field，尽管我为了整合而放弃了练习。


有一段时间，我也不喜欢m_字首。但是，在成员函数的实现代码的主体中区分成员名称和本地名称是非常可取的，并且它是

。
输入m_的努力肯定要少得多。而不是this->在前面

的名字。


在我以前工作的公司，我参与了重构我们的

C ++编程指南。指南建议使用

下划线前缀作为成员数据名称违反规则

，它为C ++编译器的实现保留了这些名称和

标准库。所以我们将其更改为m_而不是

领先下划线，每个人都很满意。


我们的一个开发人员没有使用* any *前缀。他坚持写这样的

这样的东西：


class foo

{

private：

std :: string name;

std :: string addr;

std :: string city;

std :: string state;

public：

void init（）;

/ * etc. * /

};


foo :: init（const char * name，

const char * addr，

const char * city，

const char * state）

{

this-> name = name;

this-> addr = addr;

this-> city = city;

this-> state = state;

}


这是否是灾难的秘诀？至少，即使它可能确实有效，它也非常令人困惑。

2）使用/ struct / s让我有点不舒服。有一个学校认为，这个类中出现的/ struct / s的性质应该被视为一个类，私有成员通过set和get方法访问
。这是一种非常JavaBeans的方法，在某些方面，它可能是一个合理的指导方针。


这完全取决于IMHO如何使用结构。即使在高度面向对象的代码中，结构也有它们的价值。

从我在TC ++ PL（SE）中读过的内容来看，Stroustrup可能会肯定这个问题。我提供的样本中使用的方法。从我的角度来看，/ struct / s确实为程序添加了结构，而没有引入很多由单行组成的超额代码。
使用/ struct / s作为具有私有或受保护
成员的类的替代方案可能只会使代码混乱和混淆。


同意。

OTOH，它需要（IMO），
程序员坚持礼貌，只能访问
/ struct / s就像它们是私有类成员一样。


嗯，礼貌肯定没有错。 < g>

3）这是我在AppWizardDialog课上遇到的最大问题：有一个Favo（u）仪式课，它渴望独立。我花了一些力气试图通过创建一个单独的收藏夹（原文如此）来重构代码。在这一点上，这并不是直截了当的。在目前的情况下，AppWizardDialog似乎不必要地使用代码来处理收藏夹列表。


好​​笑，我找不到你所提到的课程......

如果程序员已经拼写它会有所帮助* _favorites_ *正确！ ; - ）

Aside from the Qt idioms, with which I have never worked before, I
find the code highly structured and easy to follow. The HTML
documentation is lovely, with all the links. You can find almost
anything in any header by clicking on the symbol or name.

However, there are other issues. Not having a lot of time to invest in
this code critique, here is just one item which I noticed immediately:

I would highly recommend against using literal hard-coded values,
replacing those with constants. There are string literals sprinkled
throughout the code, but also numeric literals -- e.g. the switch
statement in the implementation of the
AppWizardDialog::licenseChanged() function. Code such as this is a
nightmare to maintain, for example, if the text needs to be translated
into another language.
I''ll just list some observations.

1) the use of m_member_field is something I''ve seen a lot. I don''t
particularly like it. My alternative is probably unattractive to most
programmers, and I will most likely have to capitulate to the majority on
this. The intent of the ''m_'' is to distinguish the variable as a member
field. My response is, that is what /this->/ is for. I do tend to use
this->member_field when referring to members of the current class, though I
am moving away from the practice for the sake of conformity.
At one time, I also didn''t like the "m_" prefix. However, it is very
desirable to distinguish between member names and local names within
the body of a member function''s implementation code, and it is
certainly a lot less effort to type "m_" instead of "this->" in front
of the name.

At the company where I used to work, I got involved in refactoring our
C++ programming guidelines. The guidelines recommended using an
underscore prefix for member data names which goes against the rule
which reserves such names for implementations of the C++ compiler and
the standard libraries. So we changed this to the "m_" instead of
leading underscore and everyone was pretty happy with it.

One of our developers didn''t use *any* prefix. He insisted on writing
stuff like this:

class foo
{
private:
std::string name;
std::string addr;
std::string city;
std::string state;
public:
void init();
/* etc. */
};

foo::init(const char * name,
const char * addr,
const char * city,
const char * state)
{
this->name = name;
this->addr = addr;
this->city = city;
this->state = state;
}

Is this a recipe for disaster or not? At the very least, it is highly
confusing, even if it might actually work.
2) The use of /struct/s makes me a bit uncomfortable. There is a school of
thought that says anything of the nature of the /struct/s that appear in
this class should be treated as a class with private members accessed
through set and get methods. That is a very JavaBeans approach, and in
some areas, its probably a reasonable guideline to adhere to.
It all depends IMHO on how the struct is used. Structs have their
place even within highly object oriented code.
From what I''ve read in TC++PL(SE), Stroustrup would probably affirm the
approach used in the sample I''ve provided. From my perspective,
the /struct/s do add structure to the program without introducing a lot of
excess code consisting of one-liners. The alternative using the /struct/s as classes with private or protected
members would probably do little more than clutter and obfuscate the code.
Agreed.
OTOH, it requires (IMO), that the
programmer adhere to good manners, and only access the members of
the /struct/s as if they were private class members.
Well, there is certainly nothing wrong with "good manners". <g>
3) This is the biggest issue I have with the AppWizardDialog class: there is
a Favo(u)rites class yearning to stand on its own. I put a little effort
into trying to refactor the code by creating a separate Favourites(sic)
class. It is not straight forward at this point to do so. In the current
situation, the AppWizardDialog seems unnecessarily cluttered with code used
to manage the favourites list.
Funny, I couldn''t find the class you refer to...
And it would have helped if the programmer
had spelled *_favorites_* correctly! ;-)

赞"和最喜欢的两者都是正确的，赞成也是正确的。和

最喜欢的。一个是英国拼写，另一个是美国拼写美国拼写。对于颜色也是如此。和颜色以及

其他单词的分数。

-

Bob Hairgrove
没有********** @ Home.com

周五，2004年5月28日14:33:46 +0200，Bob Hairgrove

< wouldnt_you_like@to_know.com>写道：


糟糕...

On Fri, 28 May 2004 14:33:46 +0200, Bob Hairgrove
<wouldnt_you_like@to_know.com> wrote:

Oops...

public：
void init（）;
/ * etc. * /
};


我忘记了声明中的论据，应该是：

public：
void init（const char *，
const char *，
const char *，
const char *）;


等


以及实现中的返回类型：

void foo :: init（ const char * name，
const char * addr，
const char * city，
const char * state）
{
this-> name = name;
this-> addr = addr;
this-> city = city;
this-> state = state;
}

public:
void init();
/* etc. */
};
I forgot the arguments in the declaration, should have been:
public:
void init(const char * ,
const char * ,
const char * ,
const char * );
etc.

as well as the return type in the implementation:
void foo::init(const char * name,
const char * addr,
const char * city,
const char * state)
{
this->name = name;
this->addr = addr;
this->city = city;
this->state = state;
}

对不起。

-

Bob Hairgrove
没有********** @ Home.com

这篇关于其他人对这段代码做了什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！