我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
这种编程是不可能的。
不是开玩笑的,我一直认为编程是一种不可能学会的东西,我总是远离它。当我接近代码的时候,我永远也无法理解它。
然后有一天,我坐下来阅读了一些基本的初学者教程,并从那里开始学习。现在我是一名程序员,我热爱工作的每一分钟。
另外,我认为编程并不容易,它是一个挑战,我更喜欢学习,没有什么比解决一些编程问题更有趣的了。
所有的语言(大部分)都是平等的。
在很长一段时间里,我认为语言的选择对开发过程的难度和项目成功的潜力并没有太大的影响。这绝对不是真的。
为工作选择正确的语言与任何其他单个项目决策一样重要/关键。
人们知道他们想要什么。
在很长一段时间里,我以为我会和人们交谈,他们会描述一个问题或工作流程,我将其放入代码并自动化。结果每次发生这种情况,他们以为自己想要的并不是他们真正想要的。
Edit: I agree with most of the comments. This is not a technical answer and may not be what the questioner was looking for. It doesn't apply only to programming. I'm sure it's not my longest-held assumption either, but it was the most striking thing I've learned in the 10 short years I've been doing this. I'm sure it was pure naivete on my part but the way my brain is/was wired and the teaching and experiences I had prior to entering the business world led me to believe that I would be doing what I answered; that I would be able to use code and computers to fix people's problems.
我想这个答案类似于Robin关于非程序员理解/关心我所谈论的内容的回答。这是关于将业务作为一个敏捷的、迭代的、交互的过程来学习。它是关于学习编程猴子和软件开发人员之间的区别。这是关于意识到两者之间的区别,并且在该领域真正优秀,不仅仅是语法和输入速度。
编辑:这个答案现在是社区-wiki,以安抚人们对这个答案感到不安,给我代表。
我相信创建程序就像在课堂上教的一样……你和一群人坐在一起,讨论一个问题,想出一个解决方案,等等。相反,现实世界是“这是我的问题,我需要解决它,开始”,十分钟后你又遇到了另一个问题,让你没有真正的时间来有效地计划解决方案。
. net结构体(c#和VB.NET)是引用类型,就像类一样。
我是在。net 1.0出现之前或之后的某个时刻“收到”这条智慧的(我不知道从哪里来的,它可能完全从我的脑海中冒出来,就像雅典娜从宙斯的额头上冒出来一样),并一直保存着它,直到大约4个月前Jon Skeet对这个概念进行了消除。
感谢乔恩。
附注:与编程无关,但我也相信(直到5分钟前)“阿波罗从宙斯的额头上长成了一个完整的阿波罗”。
c++在本质上比所有其他语言都要好。
这是我在大学前几年从一个朋友那里收到的。我带着它很长一段时间(我现在脸红了)。只有在与它一起工作了2年左右之后,我才能看到它们的裂缝是什么。
没有人,也没有什么事是完美的,总有改进的空间。
我很早就开始学习编程了。那时我14岁左右。我有各种疯狂的想法,但不要问我准确的时间,因为那是很久以前的事了。
Ok, so, I believed for a while that if you use the term synchronize in Java, then Java solves this nasting synchronizing thing for you I believed for at least half a year, likely more, that static typing would improve performance. I believed that freeing something would return memory back to the OS. I believed that malloc calls boil down to checking if there is enough free space on the OS, so malloc would be inexpensive. I thought a long while that Java was built with all the benefits and flaws of the other languages in mind, into a "perfect blend" that would take the best properties of the other languages and reject the mistakes. I vastly overestimated the number of cases where LinkedLists outperform ArrayLists. I thought that NP-hardness was a proof that no INSTANCE could be solved efficiently, which is trivially false, for a while. I thought that finding the best flight-plan on travel agency web sites would take so long because of the "Travelling Salesman Problem", as I proudly chuckled to my relatives (when I was small, alright?!)
还能想出更多。不知道我坚持了多久。对不起。
PS: 啊,好吧,这个被清除得并不慢,但我看到新手时不时地这样做,所以我想你可能会感兴趣:我还认为要存储不确定数量的东西,你需要为每个东西声明一个新变量。所以我要创建变量a1 a2 a3…,而不是使用一个变量a,我将它声明为一个向量。
用汇编语言进行优化=重写。
When I first really understood assembly (coming from BASIC) it seemed that the only way to make code run faster was to rewrite it in assembly. Took quite a few years to realize that compilers can be very good at optimization and especially with CPUs with branch prediction etc they can probably do a better job than a human can do in a reasonable amount of time. Also that spending time on optimizing the algorithm is likely to give you a better win than spending time converting from a high to a low level language. Also that premature optimization is the root of all evil...
当然,您可以查看FindBugs和PMD,但这些是我最喜欢的陷阱和技巧(所有Java):
字段没有被覆盖,而是被遮蔽。
没有显式的super。超级访问。
未定义构造函数的类具有隐式零参数构造函数。今年我犯了一个与此相关的实际错误。
要获得对内部类的父类的引用,可以使用“Outer”语法。这“消除方法调用或同步的歧义”。
在c++术语中,类是“它们自己的朋友”,该类的任何实例的私有方法和字段都可以从同一类的任何方法引用,甚至是静态方法。这将使我早期的一些clone()和copy构造函数简单得多。
在扩展类的静态上下文中可以访问受保护的方法和字段,但前提是该类在同一个包中。我很高兴flex.messaging.io.amf不是一个密封的包。
这很尴尬,但很长一段时间我都没有真正理解引用类型和值类型之间的区别。我以为你必须使用ref关键字来改变一个对象在不同的方法。
这是我应该知道的c#最基本的概念之一。
640K应该足够任何人(DOS)。多年来,很多人都相信这一点。
当我第一次拥有8MB内存的系统时,我认为这远远超过了我的需求。它可以运行操作系统(Mac)以及我使用的所有应用程序(Word、Email、Firefox等)。
我认为我应该尽可能地进行抽象。我的脑袋被这个撞了,因为太多交织在一起的小功能。
现在我试着让事情尽可能的简单和分离。重构使事物抽象比预测需要如何抽象要容易得多。
因此,我从开发规则它们的框架转移到完成工作的功能片段。从来没有回头,除了当我想起那段时间,我天真地认为我会是那个开发下一个大东西的人。
所有面向对象语言都有相同的面向对象概念。
Java接口=方法的接口。 Java接口是针对需要具有多重继承的特定于语言的解决方案。Ruby的mixin尝试解决同样的问题。 Javascript中提供的开箱即用的继承与Java实现继承的方式非常不同。
当主流设计模式在计算机科学课上被引入时,我认为它们很棒。在此之前,我有8年的编程经验,对于如何创建好的抽象概念,我真的没有扎实的理解。
设计模式就像魔法一样;你可以做一些很棒的事情。后来我发现了函数式编程(通过Mozart/Oz、OCaml、后来的Scala、Haskell和Clojure),然后我明白了许多模式只是样板,或者额外的复杂性,因为语言表达能力不够。
当然,几乎总是有某种模式,但它们在表达性语言中处于更高的层次。现在我一直在用Java进行一些专业编码,当我不得不使用访问者或命令模式等惯例而不是模式匹配和更高阶函数时,我真的感到很痛苦。
如果你看不懂我的代码,那你就是不懂这门语言。我有一些代码审查,我试图反击。
我又花了几年的时间才明白,有一个时间和地点可以让你的代码变得神奇,那就是在库中,而不是在应用程序中。该应用程序是为了清晰和可读性。Magic最好隐藏在扩展方法和框架后面。
在c++中,很长一段时间我都在想编译器在给纯虚方法定义时拒绝你。
当我意识到我错了时,我很吃惊。
很多次,当我告诉别人为其抽象类提供其纯虚析构函数的默认实现时,他/她都用大大的眼睛看着我。我知道接下来会有一场长时间的讨论……这似乎在c++初学者中是一个普遍的信念(我认为我自己也是如此)。我目前还在学习!)
Wikipedia链接到c++的纯虚拟方法
这个:
SomeClass object(initialValue);
这:
SomeClass object = initialValue;
保证在c++中是等价的。我认为第二种形式肯定会被解释成第一种形式。并非如此:请参阅c++初始化语法。
如果每一行都计算条件,如果你写这样的代码:
Dim a as Boolean = True
If a Then
Console.WriteLine("1")
a = False
Console.WriteLine("2")
Else
Console.WriteLine("3")
End If
那么输出将是:
1
3
我曾经认为应用程序的大部分工作实际上是编程。我相信这在某些情况下是正确的,但根据我的经验,我花了更多的时间来研究、记录、讨论和分析,而不是实际编码。(我从事的是操作基于激光的传感器的软件,确定如何最好地控制硬件比编写代码更具挑战性。)
我也曾经认为,程序员可以回头问旁边的人问题的开放环境是程序员团队敲定解决方案的最佳环境。事实证明,不管有没有团队,一个黑暗孤独的房间效率更高。
当我毕业时,我认为专业编程就像在大学编程一样,这意味着我将得到输入和预期输出,并被要求填写进行转换的黑框。在现实中,我必须弄清楚输入,输出和黑盒。
我过去并不认为市场和销售人员是人类的祸害,太天真了。
以前从未见过整数提升… 并认为'z'在这段代码中可以容纳255:
unsigned char x = 1;
unsigned char y = 2;
unsigned char z = abs(x - y);
z的正确值是1
我仍然对以下的一些误解感到困扰——尽管我知道这些误解是正确的,但我仍然试图抓住它们不放:
All stakeholders will make decisions about software design objectively. Those that aren't embroiled in writing the code make all sorts of decisions based entirely on emotion that don't always make sense to us developers. Project budgets always make sense - I've seen companies that are quite happy to drop [just for example] $50,000 a month for years rather than pay $250,000 to have a project completed in 6 months. The government for one loses their annual budget if they don't spend it - so spend it they will, come hell or high water. It astounds me at how many project dollars are wasted on things like this. You should always use the right tools for the right job - sometimes this decision is not in your hands. Sometimes it comes down from on high that "thou shalt use X technology" for this project, leaving you thinking "WTF! Who came up with that ridiculous idea?"... the guy paying your paycheque, that's who, now get it done. Programming ideology comes first and foremost, everything else is secondary. In reality, deadlines and business objectives need to be met in order to get your paycheque. Sometimes you make the worst decisions because you just don't have time to do it the right way... just as sometimes that word is on the tip of your tongue but the minute it takes to recall it makes you choose a different and less ideal word. There isn't always time to do it right, sometimes there is only time to do it - however that may be. Hence oft' seen anti-patterns used by so called experienced developers who have to knock out a solution to a problem 10 minutes before the presentation deadline for the software being delivered to your best client tomorrow.
事实证明,在Linux下是否检查内存分配是否返回一个引用并不重要,因为它实际上会欺骗你,在未来的某个时候实际分配内存,或者如果它没有你需要的内存,就完全终止你的程序。
Windows中的线程很便宜。
事实证明,这只是部分正确。线程有一定的开销,需要自己的地址空间,在那里它可以生存和快乐。因此,如果我发现自己在一个应用程序中处理数十个线程,我会问自己如何将所有内容简化并整合到更少的线程中。
我写的所有东西在可预见的未来都会失败。
并不是说一切最终都不会崩溃,而是在我的编程教育早期,当我发现try. catch块…我把所有的东西都包在里面....有些事情,如果失败了,将代表比我的程序处理的更大的问题(例如,北极和南极互换了位置)。
作为一名老的过程式程序员,当我第一次开始为一个业余项目用Java编程时,我并不真正理解OO。编写了大量的代码,却没有真正理解接口的意义,试图通过将所有东西都强制放到继承层次结构中来最大化代码重用——当一个层次结构无法容纳清理时,希望Java具有多重继承。我的代码成功了,但我现在对早期的东西感到畏缩。
When I started reading about dynamic languages and trying to figure out a good one to learn, reading about Python's significant whitespace turned me off - I was convinced that I would hate that. But when I eventually learned Python, it became something I really like. We generally make the effort in whatever language to have consistent indent levels, but get nothing for it in return (other than the visual readability). In Python, I found that I wasn't doing any more effort than I had before with regard to indent levels, and Python handled what I'd been having to use braces or whatever for in other languages. It makes Python feel cleaner to me now.
当我在TI-83上编程时,我认为你不能给变量赋值。因此(忽略这是C代码,不是TI-BASIC)而不是编写
c = c + 1;
我会写
d = c + 1;
c = d;
当我学习+=和++时,我惊呆了。
这种编程软件需要扎实的高等数学基础。
在我开始编程之前,我总是被告知要成为一名优秀的程序员,你必须精通高级代数、几何、微积分、三角函数等。
十年后,我只做过一次八年级学生做不到的事。
Unix和Linux操作系统设计得很好……我可能应该限定这个(!)
首先,这一观点被一些反真理的观点所强化,例如:
每个后续开发的操作系统最终都以对Unix的拙劣重新设计而告终(Lisp也是如此,在那里它更正确)。 构成“Unix哲学”的一系列规则。这并不是说他们错了,而是暗示Unix本身紧跟他们的步伐。
更确切地说,它们设计得很好/做得很好,当然其中一部分确实如此,但即便如此,这也只是相对的判断,相对于一些糟糕的Windows版本。下面是一些做得不好的事情的例子:
配置一团糟,特别平面文件配置不好 C语言在很久以前就应该被(类似D语言的)语言所取代 Shell脚本是精神分裂。它不利于开发,因为它是为快速输入而设计的速记。 目录结构命名不当 GNU工具链是不必要的神秘 一般目的总是胜过特殊目的的信念
总的来说,它们需要不必要的专业知识来操作。或者更确切地说,有大量的知识,而只有适度的理解。
也不全是坏事。Linux在政治上更好,不会被业务需求所破坏,但遗憾的是,在很大程度上,很多技术高地已经失去了。
就查询性能而言,SQL WHERE子句中整数的位比较实际上是免费的。
碰巧,对于前50万行左右来说,这在某种程度上是正确的。在那之后,它被证明是完全无联合国的。
在很长一段时间里,我认为其他人对所有编程概念(设计模式、最新的新语言、计算复杂性、lambda表达式,只要你能想到的)都了如指掌。
阅读博客、Stack Overflow和编程书籍似乎总是让我觉得自己在所有程序员必须凭直觉知道的事情上落后于潮流。
随着时间的推移,我意识到我实际上是在将我的知识与许多人的集体知识进行比较,而不是单个人,这对任何人来说都是一个相当高的标准。现实世界中的大多数程序员都有完成工作所需的知识缓存,并且有不少领域是他们薄弱或完全不了解的。
从大学时代起,我就认为自己是编程大师。因为我能写代码,而别人不会。但当我加入一家公司时,我发现自己对基本知识一无所知。我对自己的所有假设都是错的!现在我知道我需要知道什么和不知道什么了!
上大学的时候(90年代中期),他们的计算机实验室只有Windows 3.11的机器(我知道,很奇怪的大学)。
有一段时间,我认为作为一个专业程序员,只有Windows平台与我相关,而所有其他平台都只是从历史的学术角度来看有趣。
从学校毕业并学习了现代unix和linux环境后,我不禁对我蹩脚的学校感到愤怒和失望。
我现在还不敢相信,我在计算机工程学位毕业时从未见过bash shell,甚至没有听说过emacs或vim。
在不浪费字节和CPU周期的情况下编写高效的程序是非常重要的。
但随着经验的积累,它与字节或CPU周期无关,它与你的思想流有关,连续的,不间断的,就像一首诗。
本质上,不要太努力。
代码审查是浪费时间。
从一家完全可选的公司搬到一家强制性的公司(甚至是被审计的),我逐渐明白了它们的用处。对代码有另一双眼睛,即使是最琐碎的部分,也可以:
A)当你搞砸了一些琐碎的事情时,避免你的尴尬(例如,在我之前的工作中,一个琐碎的代码审查可以防止我们向客户发送数百封垃圾邮件)
B)可以教给你你一开始不知道的东西(我在我目前的工作中学习了新的库——不可避免的是在一家大公司,有人已经偶然发现了你的问题,并做了更好的解决工作——这只是知道在哪里寻找的问题)
C)至少要确保除了你自己之外还有其他人知道事情是如何运作的。
最后,我对我在这里提交的代码比我以前的工作更满意,尽管那时我认为我什么都知道:)
聪明人总是比我聪明。
当我犯错误的时候,我真的可以痛打自己,经常因为自嘲而被责备。我曾经敬畏地看着许多开发人员,并经常假设,既然他们在X方面比我知道得多,他们就比我知道得多。
随着我不断积累经验,认识更多的人,我开始意识到,虽然他们在某一特定领域比我知道得多,但他们并不一定比我/你聪明。
这个故事告诉我们:永远不要低估你的能力。
我的错误假设:虽然总是有一些改进的空间,但就我而言,我已经是一个尽可能好的程序员了。
当我刚从大学毕业的时候,我已经用C语言编程6年了,知道所有关于“结构化编程”的知识,认为“OO”只是一种时尚,并认为“天哪,我很好!!”
十年后,我在想“好吧,那时候我远没有我想象的那么好……现在我有了多态性的想法,以及如何编写干净的OO程序…现在我真的很好。”
所以,不知何故,我总是很好,但也总是比以前好得多。
在那之后不久,我终于有了“一些”谦卑。总是有更多的东西要学(还没有用像Haskell这样的纯函数式语言写一个合适的程序)。
与UNIX相比,NT操作系统的设计有缺陷。事实证明,NT内核和设计决策与任何现代的UNIX类系统非常相似,内核中的大多数问题都是由有漏洞的公司编写的第三方漏洞驱动程序造成的。
以某种方式,一个运营大量相当高调/高流量网站的公司实际上知道他们在做什么。结果他们在很大程度上毫无头绪,而且非常幸运地处于他们所处的位置。所以我想寓意是,
可靠的软件工程和最佳实践=业务成功
还是……
大多数关键的软件系统==垃圾
分析和性能分析是一回事。
然后我发现,虽然分析器总比没有强,但它包含错误的假设,比如:
只有总量才重要,细节无关紧要 统计精度是定位性能问题的必要条件 测量时间和定位不必要的耗时操作是一回事
不是持有时间最长的,但在某一时刻,有几年的时间,我:
以为微软Windows是世界上唯一的操作系统(那是1992年) 了解DOS对于拥有“高级”操作系统知识已经足够了。
这就是为什么我在高中没有选择“计算机课程”。我以为我对计算机已经了解得够多了。
后来在大学里,出于我的错误:
我认为UNIX操作系统/程序是完美的,DOS/Windows永远不会接近它(那时候看起来很真实,我猜Linus也是这么想的,这就是为什么Linux和UNIX如此相似,而不是。其他操作系统)
最后,在很长一段时间里,我想:
只有我的软件很糟糕,而商业软件是完美无缺的,因为……它是“商业”软件 美国的软件/工程师/产品是优秀的同义词,其他的都只是糟糕的尝试。
这是因为我在我的“标准”环境中构建了软件,它可以在每个人的机器/服务器上工作。只是发现我安装了一些实际上正在使用的不知名的库和服务。然后发现我利用了一个漏洞,这个漏洞后来被修补了。
您无法诊断生产中的“间歇性错误”。重新启动服务器是解决这个问题的唯一方法。
也许在我早期的ASP编码中更真实。但是有很多很好的分析工具可以发现内存泄漏和其他奇怪的问题。Perfmon还提供了许多良好的诊断数据。另外,您应该在应用程序中编写诊断日志。
In the early days, most personal computers had a cassette tape interface for loading and storing programs. I did not have a computer at this time but read everything I could get my hands on (mostly magazines) that had anything to do with computers (this was the late 70's - no internet for me). For some reason I was under the impression that programs were executed directly from the cassette tape and that the only reason computers had any RAM was to store variables while the program ran. I figured that when the code had to execute a jump instruction, it would somehow rewind or advance the tape to the correct position and continue from there.
我一直认为,任何为任何语言编写任何代码的人都会使用编辑程序。
I was working with a client of mine who had me on mostly as support and to write some of the more complex things for him. Well one day he messed up a file, big time. He accidentally saved over three hours worth of his own work, and when I asked him why he didn't save more often he replied with, "because I wasn't done". Naturally, this was not an acceptable answer, and I poked and prodded a little further. I eventually came to find out that he he has never used any editing program, EVER! Not even notepad.exe! He had been using an online CPanel editor for files! It didn't even have a 'Find' function. He couldn't ever save until he was done because he was editing the live file on the site!
不用说,我很惊讶,他至今仍在使用CPanel编辑器……
字节和字符实际上是一回事——“ASCII”只是将字节值映射到屏幕上的符号的一种方式。
阅读关于Unicode的文章真的让我大开眼界(尽管我仍然没有完全理解它)。
大的注释/代码比率是一件好事。
我花了一段时间才意识到代码应该是自文档化的。当然,如果代码不能更清晰,或者有重要的原因,这里或那里的注释是有帮助的。但是,一般来说,最好还是把注释时间花在重命名变量上。它更清晰,注释不会与代码“不同步”。
我持有时间最长(因此也是代价最大)的错误假设是:“业务需求是理智和合理的,我只是还没有理解它们。”
100个绿色假设坐在墙上, 如果一个绿色假设不小心掉了, 墙上有99个绿色假设。
交替:
胖墩儿坐在墙上。 矮胖子摔了一跤, 所有国王的马,所有国王的人, 艾菲姆说,他只是个技术人员。
一个WTF总是一个糟糕专业的证据。
事实上,我最近才意识到在我的职业生涯中有多少WTF,但当StackOverflow告诉我它们只是另一个软件指标时,我感到欣慰。
订阅许多RSS订阅,阅读许多博客并参与开源项目是很重要的。
我意识到,真正重要的是我花了更多的时间来写代码。我有阅读和关注许多博客的习惯,虽然它们是丰富的信息来源,但真的不可能吸收所有的东西。平衡阅读是很重要的,要多强调练习。
Reg。开源的话,我怕我不会受欢迎。我尝试过参与开源项目,大部分都是。net。看到许多开源项目甚至没有遵循适当的体系结构,我感到震惊。我看到。net中的一个系统没有使用分层架构,数据库连接代码到处都是,包括后面的代码,我放弃了。
这真的很尴尬,但当我开始学习如何编程时,没有什么能让我满意。我想写电子游戏。而不是这些书里让我写的那些琐碎的小程序。所以我决定跳过10章,忽略基础知识。
所以我基本上忽略了变量!
问题是我没有从惯例中识别关键字:
Car car = new Car(); //good
Car test = new Car(); //wrong must be lowercase car!
for (int i = 0; i < 10; i++) //good
for (int test = 0; test < 10; test++)//wrong must be i
我这样做了一年多,甚至用3000行字做了一个井字游戏! 当时我为自己的厉害而激动不已,直到我在互联网上找到了150行一字棋。然后意识到自己是个白痴,就重新开始。
我是一名初出茅庐的年轻开发者,希望从事专业的开发工作,因为这是我所热爱的,以下是我曾经持有的一些观点,这些观点都是我在短暂的经验中学到的,但都是错误的
当你根本不把用户界面和逻辑分开时,你最终会遇到的可怕的混乱是可以接受的,这也是每个人写软件的方式
不存在太多复杂或抽象的东西
一类责任——我从未真正有过这个概念,它对我来说是非常正式的
测试是我在卧室里编写代码时不需要做的事情
我不需要源代码控制,因为它对我所做的项目来说是多余的
开发人员什么都做,我们应该知道如何设计图标和做出漂亮的布局
Dispose并不总是需要结束符
任何类型的错误发生时都应该抛出异常
异常是针对错误情况的,很多时候只返回一个指示失败的值就可以了。我最近才明白这一点,我一直在说这一点,并且在很长一段时间内仍然抛出异常
我可以编写一个完全没有错误的应用程序
在80年代早期,当我开始玩电脑(ZX81, 1K内存)时,我花了几个小时为杂志上的游戏输入大量的机器代码(字节,而不是人类可读的汇编语言),基本上是使用BASIC Poke指令。
我相信,如果我输入了一条错误的指令,那么我就必须从头开始,从头开始输入机器代码。
C/ c++中if语句的求值顺序是特定于编译器的。所以写作:
if (pointer != NULL) && (pointer->doSomething())
是不安全的,因为可以交换求值顺序。我最近发现(在多年的谎言之后),它是ANSI-C规范的一部分,您可以保证订单和它的完全安全。
詹姆斯
评论越多越好。我总是试图让我的代码尽可能具有可读性——主要是因为我几乎肯定是那个会修复我漏过的bug的人。所以在过去的几年里,我经常会收到一段又一段的评论。
最终,我明白了,有一个点,更多的评论——无论结构多么整齐——没有增加价值,实际上成为一个麻烦的维护。这些天,我采取了目录+脚注的方法,每个人都为此感到高兴。
在学校里,你被教导编程是“读取输入,处理数据,写输出”。实际上,很少有处理步骤——大多数编码只是“读取输入,输出”。
一般来说,它要么是“从用户读取,写入数据库”,要么是“从数据库读取,显示在屏幕上”。这两种情况涵盖了大约95%的工作。
我最大的先入之见是,我将被允许以我想要的方式编程。当然,后来我离开了大学,进入了一家拥有荒谬框架、规则和程序的公司,这不仅意味着我不能以自己想要的方式编程,而且意味着我编程得很糟糕。
I thought I'd be coding for 8 hours straight. Realistically, I get 4 hours a day of coding, 1 hour for lunch, 1 for coffee breaks, and 2 for screwing around / chit chatting/ stack over and under flowing. Prior to working, I thought that all clients would be idiots and don't know two craps about computers. Boy was I wrong on that one. Sometimes, we get projects by people who can do it better than we can, they just don't have the time to do it. I thought cubicles were bad, Right now I love them :D I actually moved from a door-ed office to a cubicle. I like the openness. All programmers are not athletic. I thought that I was the only one that goes to the gym. Where I work, at least 10 of us go to the gym every day at 5 am. I thought there would be no women programmers. A couple of our leads are ladies.
My co-workers were/are producing supposedly bad code because they sucked/suck. It took me a while to learn that I should first check what really happened. Most of the times, bad code was caused by lack of management, customers who didn't want to check what they really wanted and started changing their minds like there's no tomorrow, or other circunstances out of anyone's control, like economic crysis. Customers demand "for yesterday" features because they are stupid: Not really. It's about communication. If someone tells them it everything can really be done in 1 week, guess what? they'll want it in 1 week. "Never change code that works". This is not a good thing IMO. You obviously don't have to change what's really working. However, if you never change a piece of code because it's supposedly working and it's too complex to change, you may end up finding out that code isn't really doing what it's supposed to do. Eg: I've seen a sales commission calculation software doing wrong calculations for two years because nobody wanted to maintain the software. Nobody at sales knew about it. The formula was so complex they didn't really know how to check the numbers.
Java将对象的副本传递给函数,而不是引用。
换句话说,我认为如果你将一个对象传递给一个方法,然后以某种方式改变对象,它不会改变调用范围内的对象。我总是将对象传递给方法,操作它们,然后返回它们!
我一直认为,要成为一名优秀的程序员,必须了解系统的所有内部工作原理。我很羞愧,因为在开始编码之前,我不知道关于这门语言的一切,比如它的库、模式、代码片段。 我不再那么天真了。
Python是一种不切实际的、令人讨厌的语言(我仍然可以读到一些关于我早期代码的注释,抱怨它),而c++是唯一真正的面向对象语言。
我错得太离谱了,到现在还觉得羞愧。
我需要定义所有的变量,我将使用在我的函数在其开始(Pascal风格)。
我曾经相信我需要考虑我的函数使用的所有资源,并在我开始编码之前定义它们,这可能是因为我的第一门语言是Pascal,这是要求。然后当我转移到C语言时,我会定义只在这些循环之外的循环中使用的临时变量,忽略循环内作用域,只是为了“一切都将在开始时定义”。
我花了几年时间才明白,提前定义所有资源并不是一件容易的事,而且范围本身对代码可读性非常重要。
OOP的好处是你可以重用对象,而实际上它是通过创建一个具有相同接口的新对象来重用其余的代码。
实际上,对象可能占代码的2%,因此重用只会给您带来2%的好处。真正的好处是通过创建一个新对象来重用其他98%的代码,从而允许所有其他代码完全不同。现在您重用了98%的代码。把一个东西写为一个对象所花费的时间延长3倍是值得的。
例如,如果你有一个绘图程序,突然有一个你想要绘制的新形状,你只需要改变ShapeObject(同时保持界面相同)。项目中的其他内容都不需要改变。
当我第一次听说“鸭子打字”时,我以为它实际上是“管道打字”,类似于人们经常说的鸭子胶带。“Duck typing”听起来是错误的,而“pipe typing”则有一种奇怪的意义(拼凑的类型)。
至少6年来,我一直坚信,每个问题都只有一个解。
完全不知道不同复杂性的多种算法、空间/时间的权衡、面向对象、功能和命令式、抽象级别和无法确定的问题。当那种幸福的天真被打破时,它打开了一个充满可能性的世界,关上了坐下来建造东西的大门。我花了很长时间才弄清楚怎么选一个然后用它来运行。
我可以说服传统的过程程序员,为什么OOP经常提供更好的解决方案。
也就是说,一种描述世界的语言需要有描述复杂对象及其关系的能力。
争论通常包括关于抽象类的废话,我的回答是“不是所有的OOP程序员都刚从Uni毕业,还沉迷于抽象”。或者是经典的,“在面向对象编程中,没有什么是我用严格的过程式编程做不到的”,对此我通常会回答,“不是你能做到,而是如果你有一个更广泛的工具集,你是否会做到”。
我已经学会接受他们和我看世界的角度不同这一事实。
没开始做的事,永远做不完。
看起来真的很愚蠢,但我推迟了这么多项目,因为规模太大了。我刚刚完成了一个巨大的项目,我意识到如果我意识到它的范围,我就不会开始了。在现实中,即使是最复杂的系统,当被分解成离散的和明确的部分时,也是相当简单的。然而,从宏观层面来看,它很快就被压倒了。
PHP的mysql_fetch_row是从执行的SQL查询中检索数据的唯一方法。
老实说,我编写了一个完整的web应用程序,而没有使用mysql_fetch_array,并且每次我想要更改函数以添加额外的列时都必须更改一堆数字。
我曾经认为ie6的盒子模式是微软为了破坏与其他浏览器的兼容性而想出的一个邪恶的愚蠢想法。
大量的csing使我相信它更符合逻辑,并且可以使页面设计维护(更改块填充/边框/页边距)更容易。
想想现实世界:改变A4页面的边框宽度并不会改变页面宽度,只会减少内容的空间。
字节码解释的语言(如c#或f#)比那些直接编译成机器代码的重置按钮慢。
好吧,当我开始有这样的信念时(在80年代),这是真的。然而,即使是在c#中,我有时也会想“把这个内循环放到一个。cpp -文件中是否会让我的应用程序运行得更快”)。
幸运的是,没有。
可悲的是,我几年前才意识到这一点。
不熟悉SQL和关系数据库的过程开发人员/程序员不需要任何正式的培训,也不需要了解如何使用SQL,快速阅读SQL For Dummies之类的东西就足以使用像Oracle和SQL Server这样的关系数据库。
在处理存储在关系数据库(如Oracle和SQL Server)中的数据的应用程序中,许多错误往往是由于缺乏对关系数据库语言的理解或如何使用造成的;SQL。
I used to work for a software vendor who had the mentality that all a developer needed was the SQL For Dummies book or something similiar and they would be fully equipped to handle any relational database issue. Now that the clients of this vendor have databases measuring in hundreds of gigabytes this lack of SQL knowledge is coming back around in a negative way. It's not just bad performing lookups and or updates and inserts that are a problem but the actual design of the database itself that is the real obstacle.
如果当时开发主管能够像对待他们构建应用程序所用的语言那样对待SQL和关系数据库,那么所有这些都是可以避免的,而且成本也会低得多。
不要认为SQL不重要,因为它最终会回来困扰你。你可能可以在一段时间内摆脱它,甚至几年,但你最终会达到一个断点,在没有完全重新设计数据库的情况下,你无法继续前进,那是成本最高的时候。
我通过阅读K&R自学了C。不幸的是,我没有逐字逐句地读,肯定漏掉了一些东西。我编写了我自己的malloc和calloc版本,我在不同的工作中都随身携带,因为我不知道你可以只链接现有的库。我这样做了好几年,直到最后有人问我为什么要带着这些东西到处走,“嗯……你知道你可以直接链接现有的库,对吧?”
:
for (int i = 0; i < myObj.variable; i = i + 1)
优化为:
int j = myObj.variable;
for (int i = 0; i < j; i = i + 1)
哇,当我意识到它们每次都在运行时,我停止在j的地方放入函数调用!
原因:
for (int i = 0; i < myObj.variable; i = i + 1){
if (function_argument == NULL){
myObj.variable++;
} else {
printf("%d", myObj.variable);
}
}
并不等同于:
int j = myObj.variable;
for (int i = 0; i < j; i = i + 1){
if (function_argument == NULL){
myObj.variable++;
} else {
printf("%d", myObj.variable);
}
}
任意的例子,但是您可以看到优化将如何改变执行。
@Kyralessa: It's worth noting that on most processors, in assembly/machine language, it's possible for functions to return someplace other than their caller while leaving the stack in good condition. Indeed, there are a variety of situations where this can be useful. One variation I first saw on the 6502, though it works even better on the Z80, was a print-message routine where the text to be printed immediately followed the call instruction; execution would resume after the zero terminator (or, as a slight optimization when using the Z80, at the zero terminator, since letting the zero byte be executed as a NOP would be cheaper than trying to avoid it).
有趣的是,在许多现代语言中,函数都有一个正常的退出点(将在调用之后恢复执行),但也可以通过抛出异常退出。即使在C语言中,也可以使用setjmp/longjmp来模拟这种行为。
唯一的本地化/国际化问题是翻译消息。
我曾经认为所有其他语言(我没有语言环境的概念)在各个方面都像英语,除了单词和语法。因此,要本地化/国际化一个软件,您只需要让翻译器翻译显示给用户的字符串。然后我开始意识到:
有些语言是从右向左书写的。 一些脚本使用上下文塑造。 日期、时间、数字等的格式有很大的变化。 程序图标和图形可能对某些人群毫无意义或具有冒犯性。 有些语言有不止一个“复数形式”。 ...
即使在今天,我有时也会读到令我惊讶的国际化问题。
做事总有一种“正确”的方式。大学毕业后很长一段时间,我一直抱着这个想法。
当然,我意识到完成一项任务总有很多种方法。每种方法都有优点和缺点。查看可用的信息,做出决定,然后确保你能向你的老板证明这一点。
在我刚开始学习c++的时候(很多时候),我周围都是Java学者。当被问及c++相对于Java的优势时(我通常会认为这是一个做作的问题,但就是这样),我会在我的回答中包括c++提供了引用和指针。Java的家伙会看起来难以置信,并建议引用是指针,并把我笑出了房间。我坚持在c++中引用和指针是不同的。
说句公道话,我是对的。引用和指针在语义和语法上是不同的。不幸的是,我用一个谬论来支持我的说法:底层实现是不同的。
我坚信,通过标准化,引用是语法中的名称别名,就像typedef是没有存储空间的类型别名一样。
我确信引用不是对象,也没有存储空间,它们只是提供了从“名称”到“对象”的多个顶级映射。在这方面,我认为它们就像文件系统中的软链接:
Code: int a = 3; int& b = a;
Names Objects Memory
+-----+ +-------------+ +-------+
| a |---->| | | |
+-----+ | | | |
| int |---->| 3 |
+-----+ | | | |
| b |---->| | | |
+-----+ +-------------+ +-------+
当然,尽管优化可能会导致这种情况,但引用确实有存储空间。它们是不同的对象,即使语法尽力将其从程序员那里抽象出来。
可以这么说,我很失望地了解到,关闭优化的编译器可能会将引用作为指针实现,需要一个解引用操作:我实际上是在文件系统中创建一个硬链接的类比:
Code: int a = 3; int& b = a;
Names Objects Memory
+-----+ +-------------+ +-------+
| a |---->| int |---->| |
+-----+ +-------------+ | |
| 3 |
+-----+ +-------------+ | |
| b |---->| int& |---->| |
+-----+ +-------------+ +-------+
标准c++实际上并没有指定引用应该如何实现,所以我的理论可能适用于一些工具链,但在任何主流编译器中都不适用……当然标准中也没有说明。