不要开始一场火焰战，但...... [英] Not to start a flame war, but...

问题描述

不要开始一场火焰战，但是？


我过去几个月一直在用C＃编程，但是我

am随着它变得越来越激烈。我的理由是

以下，但我想知道其他人的经历是什么。我认为我可能会在whidbey的时间框架内切换到vb.net，如果事情没有改变，那么
。


理由：

1.为什么在输入枚举数据类型之后没有intellisense

由=符号？为什么我要输入枚举+的类型？获得智能感知的
。我有一个习惯，就是给出枚举冗长的名字（使代码自我记录的代码是b / b）这种习惯让我输入一个地狱

比我更多想要。例如：


this.WindowState =？在世界上哪里是intellisense。我必须输入以下内容才能获得以下内容：

this.WindowState = FormWindowState。


这太荒谬了。 />

2.疯狂的傻转换和演员阵容。


int x;

x = FormWindowState.Normal; //这不会编译

x =（int）FormWindowState.Normal; //这个编译


为什么在世界上我需要将FormWindowState.Normal转换为int，如果

它还是一个整数？不应该在

编译时解决这个问题吗？据我所知，有人@MS去了并赢得了语言

功能jihad，但这只会导致生产力下降。 VB

（-option strict）很好地解决了这个问题，我从未遇到过问题。


3.对于WinForm应用程序，在代码视图中在表单中，不可能快速找出对象可用的事件（如按钮

或复选框或其他）。你必须切换到窗体视图，转到

属性，切换到事件，然后你会看到它。为什么这么疯狂？

为什么不只是复制vb.net方法。 vb.net团队只有一个

楼，只是去找他们。


还有其他的抱怨，但我太累了。

Not to start a flame war, but?

I?ve been programming mostly in C# for the last couple of months, but I
am quickly becoming more and more aggravated with it. My reasons are
below, but I was wondering what other people?s experiences are. I am
thinking that I?ll probably switch to vb.net in the whidbey time frame,
if things don?t change.

Reasons:
1. Why is there no intellisense after I type an enum data type followed
by the = sign? Why do I have to type the type of the enum + ?.? to get
the intellisense. I had a habit of giving enums verbose names (to make
the code self-documenting) and this habit is causing me to type one hell
of a lot more than I want to. Example:

this.WindowState = ? where in the world is the intellisense. I have to
type the following to get it:
this.WindowState = FormWindowState.

This is ridiculous.

2. Insane amount of silly conversions and casts.

int x;
x = FormWindowState.Normal; //this will not compile
x = (int) FormWindowState.Normal; //this compiles

Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn?t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I?ve never had a problem.

3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you?ll see it. Why such insanity?
Why not just copy the vb.net approach. The vb.net team is only one
floor away, just go and ask them for it.

There are other gripes, but I am just too tired.

推荐答案

Frank Rizzo< no ** @ none.com>写道：

Frank Rizzo <no**@none.com> wrote:

不是要开始一场火焰战，但是？

我过去几个月一直在用C＃编程，但我很快就会变得越来越恶化。我的理由如下，但我想知道其他人的经历是什么。我认为我可能会在whidbey的时间框架内切换到vb.net，
如果事情没有改变。

原因：
1。在键入=符号后面的枚举数据类型后，为什么没有智能感知？为什么我要输入枚举+的类型？获得智能感知。我习惯于给予枚举冗长的名字（使代码自我记录），这种习惯让我输入了比我想要的更多的地狱。示例：

this.WindowState =？在世界上哪里是intellisense。我必须输入以下内容才能得到它：
this.WindowState = FormWindowState。

这太荒谬了。


我相信这在惠德贝已经有所改善，但我个人从来没有用过这么大的问题。不要忘记你仍然可以在枚举的名称上获得智能感知，例如：按F然后按

Ctrl-Space来获取一些你可以减少的东西列表

FormWindowState而不必输入整个东西。

2.疯狂的傻转换和演员阵容。

int x;
x = FormWindowState.Normal; //这不会编译
x =（int）FormWindowState.Normal; //这个编译

为什么在世界上我需要将FormWindowState.Normal转换为int，如果
它已经是一个整数了？不应该在编译时解决这个问题吗？据我所知，有人@MS去了并且赢得了语言
功能jihad，但这只会导致生产力下降。 VB
（-option strict）很好地解决了这个问题，我从未遇到过问题。


FormWindowState *虽然不是一个int。这是一个基于枚举* *的int，

但它本身并不是一个int。这只是C＃严格关于它的

打字，我认为这很好。

3.对于WinForm应用程序，在表单的代码视图中，这是不可能的快速找出对象可用的事件（如按钮
或复选框等）。你必须切换到窗体视图，转到
属性，切换到事件，然后你会看到它。为什么会出现这样的疯狂？
为什么不直接复制vb.net方法。 vb.net团队只有一个楼层，只需去找他们。

Not to start a flame war, but?

I?ve been programming mostly in C# for the last couple of months, but I
am quickly becoming more and more aggravated with it. My reasons are
below, but I was wondering what other people?s experiences are. I am
thinking that I?ll probably switch to vb.net in the whidbey time frame,
if things don?t change.

Reasons:
1. Why is there no intellisense after I type an enum data type followed
by the = sign? Why do I have to type the type of the enum + ?.? to get
the intellisense. I had a habit of giving enums verbose names (to make
the code self-documenting) and this habit is causing me to type one hell
of a lot more than I want to. Example:

this.WindowState = ? where in the world is the intellisense. I have to
type the following to get it:
this.WindowState = FormWindowState.

This is ridiculous.
I believe this has improved in Whidbey, but personally I''ve never had
that much of a problem with it anyway. Don''t forget that you can still
get intellisense on the name of the enum too, e.g. press F and then
Ctrl-Space to get up a list of things which you can whittle down to
FormWindowState without having to type in the whole thing.
2. Insane amount of silly conversions and casts.

int x;
x = FormWindowState.Normal; //this will not compile
x = (int) FormWindowState.Normal; //this compiles

Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn?t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I?ve never had a problem.
FormWindowState *isn''t* an int though. It''s an enum *based* on an int,
but it isn''t an int itself. This is just C# being strict about its
typing, which again I think it fine.
3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you?ll see it. Why such insanity?
Why not just copy the vb.net approach. The vb.net team is only one
floor away, just go and ask them for it.

就个人而言，我还是没有使用表单设计师，所以如果我特别担心的话，我可能只有单独设置事件的单独方法。您可以随时打开设计师为您生成的代码，并找到事件处理程序。


-

Jon Skeet - < sk *** @ pobox.com>
http： //www.pobox.com/~skeet

如果回复该群组，请不要给我发邮件

Personally I don''t use the forms designer anyway, so I''d probably have
a separate method solely for setting up the events if I were
particularly worried about that. You can always open up the code that
the designer has generated for you and find the event handler anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

你列出的三个项目是个人喜好，而且很漂亮

表示某人来自VB世界的心态（并不意味着

a挖掘 - 只是真相） 。


实际上，我会给你第1项 - 缺乏enum intellisense可能是b / b
烦人。但我想这已经得到了解决。


无论如何，这正是你可以选择使用VB或C＃的原因。

Erik


" Frank Rizzo" <无** @ none.com>在消息中写道

新闻：O1 ************** @ TK2MSFTNGP09.phx.gbl ...

The three items you''ve listed are personal preferences, and pretty
indicative of the mentality of someone coming from a VB world (not meant as
a dig - just the truth).

Actually, I''ll give you item #1 - the lack of enum intellisense can be
annoying. But I guess this has been adressed.

In any case, this is exactly why you have the option to use VB or C#.

Erik

"Frank Rizzo" <no**@none.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl...

不要启动火焰战争，但是？

在过去的几个月里，我一直在用C＃进行编程，但是我很快就变得越来越烦恼了。我的理由如下，但我想知道其他人的经历是什么。我认为我可能会在whidbey的时间框架内切换到vb.net，
如果事情没有改变。

原因：
1。在键入=符号后面的枚举数据类型后，为什么没有智能感知？为什么我要输入枚举+的类型？获得智能感知。我习惯于给予枚举冗长的名字（使代码自我记录），这种习惯让我输入了比我想要的更多的地狱。示例：

this.WindowState =？在世界上哪里是intellisense。我必须输入以下内容才能得到它：
this.WindowState = FormWindowState。

这太荒谬了。

Not to start a flame war, but?

I?ve been programming mostly in C# for the last couple of months, but I
am quickly becoming more and more aggravated with it. My reasons are
below, but I was wondering what other people?s experiences are. I am
thinking that I?ll probably switch to vb.net in the whidbey time frame,
if things don?t change.

Reasons:
1. Why is there no intellisense after I type an enum data type followed
by the = sign? Why do I have to type the type of the enum + ?.? to get
the intellisense. I had a habit of giving enums verbose names (to make
the code self-documenting) and this habit is causing me to type one hell
of a lot more than I want to. Example:

this.WindowState = ? where in the world is the intellisense. I have to
type the following to get it:
this.WindowState = FormWindowState.

This is ridiculous.

" Frank Rizzo" <无** @ none.com>在消息中写道

新闻：O1 ************** @ TK2MSFTNGP09.phx.gbl ...

"Frank Rizzo" <no**@none.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl...

不要启动火焰战争，但？


[snip]

为什么在世界上我需要将FormWindowState.Normal转换为int，如果
它已经是一个整数？不应该在编译时解决这个问题吗？据我所知，有人@MS去了并且赢得了语言
功能jihad，但这只会导致生产力下降。 VB
（-option strict）很好地解决了这个问题，我从未遇到过问题。


即使使用Option Strict On，VB也会接受此分配。 VB将根据缩小/扩大规则拒绝

分配 - 例如，隐式

从Double到Integer的分配不允许使用Option Strict On。

但是，在这种情况下，你是对的。枚举只是一个集合。 （在其他

语言的术语中）Integer（默认情况下）值，以及该集合的

值之一（转换为文字字段）在事实上一个

整数。因此，完全合法的任务。但是，从一个过分严格的纯粹主义观点来看，这就是C＃的哲学，编译器

要求演员阵容为你确定你真的很想做到这一点断言。

3.对于WinForm应用程序，在表单的代码视图中，无法快速找出对象可用的事件（如按钮
）或复选框或其他）。你必须切换到窗体视图，转到
属性，切换到事件，然后你会看到它。为什么会出现这样的疯狂？
为什么不直接复制vb.net方法。


这个问题在下一个版本中得到了一定程度的解决。

vb.net团队只有一个楼层，只需去和请问他们。

还有其他的抱怨，但我太累了。

Not to start a flame war, but?
[snip]
Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn?t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I?ve never had a problem.
Even with Option Strict On, VB will accept this assignment. VB will reject
assignments based on narrowing/widening rules - for example, implicit
assignment from Double to Integer are not allowed with Option Strict On.
However, in this case, you are correct. The enum is just a "set" (in other
languages'' terminology) of Integer (by default) values, and one of the
values of that set (which translates into a literal field) is in fact an
Integer. Therefore, a perfectly legal assignment. However, from an overly
strict type purist point of view, which is the C#''s phylosophy, the compiler
requires the cast as an "are you sure you really want to do this" assertion.
3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you?ll see it. Why such insanity?
Why not just copy the vb.net approach.
This is being addressed to some degree in the next release.
The vb.net team is only one
floor away, just go and ask them for it.

There are other gripes, but I am just too tired.

好​​吧，我经常使用这两种语言。我使用哪一个是由

客户端决定的。我也不喜欢这些怪癖。总的来说，.NET

基础设施和两种语言都是我最喜欢的工作环境

in / with。我认为这两种语言同样有能力，但如果对你来说最重要的

标准是语法上较少的肛门语言，那么我建议

坚持使用VB。这是区分两者的少数事情之一，特别是在下一个版本发布之后，它更像是优先事项而不是其他任何东西。

你在抱怨中提出的一些要点是非常具体的设计目标
C＃的
，所以我怀疑你会对它感到满意。这并不像C＃团队那样丢弃了球并忘记了其中的一些东西 - 特别是

意图作为语言设计的一部分。


-Rob Teixeira [MVP]

Well, I use both languages frequently. Which one I use is dictated by the
client. There are little quirks I don''t like about either. Overall, the .NET
infrastructure and both languages are my favorite environments to work
in/with. I view both languages as equally capable, but if the most important
criteria for you is the syntactically-less-anal language, then I suggest
sticking with VB. It''s one of the few things that distinguishes the two,
especially after the next release, and it''s more a matter of preference than
anything else.
Some of the points you made in your gripe were very specific design goals
for C#, so I doubt you will be happy with it. It''s not as if the C# team
dropped the ball and forgot some of this stuff - it was specifically
intended as part of the language design.

-Rob Teixeira [MVP]

这篇关于不要开始一场火焰战，但......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！