我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。

你坚持时间最长、最终被纠正的假设是什么?

例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。

坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。


当前回答

@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来模拟这种行为。

其他回答

人们会关心最佳实践,甚至一致性。

在很长一段时间里,我认为糟糕的编程是发生在边缘的事情。正确做事是标准。我现在没那么天真了。

假设我要使程序100%完成,没有错误,并报告它为“完成”。有时,公司想要在程序存在很多漏洞时发布该程序,以抢占市场份额。

当我在TI-83上编程时,我认为你不能给变量赋值。因此(忽略这是C代码,不是TI-BASIC)而不是编写

c = c + 1;

我会写

d = c + 1;
c = d;

当我学习+=和++时,我惊呆了。

与自动化相结合的编程优雅是老式测试的充分替代品。