Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Nice and Write Stable Code

technosophos.com

Post reply on HN
Print view View original

91–100 of 159 posts

Re: Be Nice and Write Stable Code

#91

Post by dragandj »

Swizec wrote: post #80
nostalgeek wrote: post #76

Earlier quoted context omitted.

> It depends. I have a friend who used to work on banking systems. They had full test coverage of every dependency. Even standard lib functions and language features. these are not dependencies anymore then, they are part of your code source and should be vendored with it. I don't know what language your friend is using but I'm pretty sure most std libs and languages already have tests with very good coverage. > One…

The lesson learned isn’t about code coverage or oaths tested. It’s to not blindly trust 3rd part anything, even “languages already have test with very good coverage” when the stakes are high. If billions of dollars are riding on your code, you better be damn sure you trust everything it relies on. Fun side note: every piece of internal code was always developed in parallel to the same spec by 3+ teams so they could c…

Was the spec also written by the 3 teams in parallel to make sure the spec is not broken?

Re: Be Nice and Write Stable Code

#92

Post by jestar_jokin »

azernik wrote: post #19
laurence-myers wrote: post #5

SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. One man's bugfix is another man's breaking change. If product A implements a workaround for a bug in product B, but the bug gets fixed in a patch version, it could break product A's code, so it becomes a breaking change. The only way to anticipate these changes is reading the change logs/r…

Contracts are social constructs too.

In programming, type contracts are not. Wouldn't it be nice if we had some sort of infallible static analysis tool that absolutely determines what constitutes a breaking change in your codebase?

Re: Be Nice and Write Stable Code

#93

Post by zaarn »

Swizec wrote: post #80
nostalgeek wrote: post #76

Earlier quoted context omitted.

> It depends. I have a friend who used to work on banking systems. They had full test coverage of every dependency. Even standard lib functions and language features. these are not dependencies anymore then, they are part of your code source and should be vendored with it. I don't know what language your friend is using but I'm pretty sure most std libs and languages already have tests with very good coverage. > One…

The lesson learned isn’t about code coverage or oaths tested. It’s to not blindly trust 3rd part anything, even “languages already have test with very good coverage” when the stakes are high. If billions of dollars are riding on your code, you better be damn sure you trust everything it relies on. Fun side note: every piece of internal code was always developed in parallel to the same spec by 3+ teams so they could c…

Certainly it's fun from the pure engineering perspective but I guess also somewhat tedious.

On the other hand, if a billion dollars depend on your code working or not, or in other cases human lives like in space rockets, you don't get a second chance. If you fuck up, lots of important things get flushed down the toilet, usually including your job.

So you have 3 teams do in parallel to be 99.999999999% certain that it'll work as advertised. It's also sorta why banks are slow to adopt new changes since they want to be sure that whatever is going on, it'll work and not flush down Grandma's rent.

Re: Be Nice and Write Stable Code

#94

Post by flukus »

earenndil wrote: post #85
flukus wrote: post #64

Earlier quoted context omitted.

Such as? White space changes can be ignored, comments can be stripped pre diff, both version can be run through the same formatter before hand. What you're then left with are the actual changes. Anything removed or modified is a breaking change. Anything added to a public struct is a breaking change, which can and arguably should be hidden behind an interface. Adding functions is about all I can think of that's left.…

What if: * Function order changes * Prototype goes from int function(char * ); to int function(char * arg); * Typedef is added so instead of int function(char* );, it's typedef char* str; int function(str);

Good points, the second one in particular I don't think could be fixed without a full parser. Function order changes could possibly be worked around by a formatter/linter that can reorder functions, at the risk of creating more issues. The last could be handled be passing the code through the preprocessor (the -E flag in gcc) first.

By this point it's probably gone beyond the "perfect is the enemy of good" threshold though.

Re: Be Nice and Write Stable Code

#95

Post by gmueckl »

pjmlp wrote: post #71
gmueckl wrote: post #61

Earlier quoted context omitted.

C++ and C# have the same kind of problem: except for the iffy freind declaration in C++ there is no way in the language to denote that some method is bot meant for use in other modules. C# has the internal scope for each assembly, but this breaks in combination with unit tests placed in seperate testing assemblies. Generally, proper unit testing is at odds with strict scope restrictions in the tested code. I guess we…

> C# has the internal scope for each assembly, but this breaks in combination with unit tests placed in seperate testing assemblies. That is what [assembly: InternalsVisibleTo()] is for.

This only covers a small part of the problem. Things that should be private and requite separate yesting are atill required to be more visible than they are supposed to.

Re: Be Nice and Write Stable Code

#96

Post by jakobegger »

jarfil wrote: post #7

This is all great, but I feel like all these problems could be caught just with properly written tests. If your tests correctly cover the API usage of your code, and I mean both your code complying with the intended API and the API complying with the intended usage, then the implementation behind that API should be totally transparent. No need to check versions, release notes, or any of that, just run the API complia…

Relying on tests is naive. Your tests can't cover every case. The article even mentions this -- their tests passed, but it failed in production.

Re: Be Nice and Write Stable Code

#97

Post by lmm »

oweiler wrote: post #58
p2t2p wrote: post #51

Earlier quoted context omitted.

I'm doing this kind of automation with Maven in Java. There is a plugin (build helper I believe is the name) that gives you properties like "next.release.version", "current.release.version", "next.snapshot.version", etc. So I've setup an infrastructure where you just click a button and it performs a release with _proper_ version number in accordance with semver, simply does the right thing. Works like a charm. I don'…

And who decides if a change is breaking or not?

I don't know whether parent is doing this, but I used to use the Clirr maven plugin to fail the build if a release had binary-compatibility changes. You could then have a distinct release profile that permits a BC break but increments the major version number.

Re: Be Nice and Write Stable Code

#98

Post by p2t2p »

oweiler wrote: post #58
p2t2p wrote: post #51

Earlier quoted context omitted.

I'm doing this kind of automation with Maven in Java. There is a plugin (build helper I believe is the name) that gives you properties like "next.release.version", "current.release.version", "next.snapshot.version", etc. So I've setup an infrastructure where you just click a button and it performs a release with _proper_ version number in accordance with semver, simply does the right thing. Works like a charm. I don'…

And who decides if a change is breaking or not?

It's simple, everything that has existed should behave exactly as it used to before. In order to ensure this people invented lots so technics - code reviews, exploratory testing, integration tests and so on. It's even boring to discuss it, it's just basics.

Re: Be Nice and Write Stable Code

#99

Post by jopsen »

p2t2p wrote: post #51
QuinnWilton wrote: post #21

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-package, actually tries to remove humans from the equation, by automatically choosing the next version number, based on a diff of the API and the exported types of a package: https://github.com/elm-lang/elm-package#publishing-updates It's not perfect, but it's be…

I'm doing this kind of automation with Maven in Java. There is a plugin (build helper I believe is the name) that gives you properties like "next.release.version", "current.release.version", "next.snapshot.version", etc. So I've setup an infrastructure where you just click a button and it performs a release with _proper_ version number in accordance with semver, simply does the right thing. Works like a charm. I don'…

You can still break behavior without breaking the public API.

But yes, tools like this would eliminate most of the semver issues.

I can't believe such logic isn't built-in to more package managers.

Re: Be Nice and Write Stable Code

#100

Post by lmm »

marcosdumay wrote: post #49
toast0 wrote: post #35

Earlier quoted context omitted.

I don't think 'does it work exactly the same' isn't necessarily the right question, given there are expected to be bug fixes which may change the behavior in some functions.

The right question is "what's the difference between a bug-fix and a breaking change?"

A bug fix makes the function behave as it's documented to, a breaking change involves a change to the documentation?
Post reply on HN