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

111–120 of 159 posts

Re: Be Nice and Write Stable Code

#111

Post by t3soro »

Nadya wrote: post #50
marcosdumay wrote: post #49

Earlier quoted context omitted.

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

Irrelevant. If fixing a bug is a breaking change then it is a breaking change. This is the importance of pre-releases/"nightly" branches so that you don't have a mistake of addNumbers(5,5) returning 25 instead of 10 and not being caught and then needing to increment a major number to fix a typo of × to +. A bug fix is a change . A breaking change is a change that breaks the API . Doesn't matter if the previous status…

A bug fix is not a breaking change. You are speaking in tautologies. "A bug fix is a change that is a change to the API". No, bug fix does not change the interface. A bug fix does not change the API. It does not require a semantic version change unless it also changes the expected behavior of the method, in which case it is a change in the documentation, which is part of the application programming interface.

Re: Be Nice and Write Stable Code

#112

Post by HolyHaddock »

t3soro wrote: post #110
dbaupp wrote: post #43

Earlier quoted context omitted.

No, it isn't computable (that is, correctly determining one of "these functions behave the same" or "these functions behave differently", and not "unknown") in general, as it is equivalent to the halting problem. Consider these two versions of a function, are they API compatible? def foo(): return True def foo(): return halts("some turing machine program") They're only truly API compatible if the program halts, but t…

Thanks for that pedantic insight, doc. It's patently obvious that API compatibility is a computable problem. You are just checking if API1 is a subset of API2. Even if foo() never returns, the Application Programming Interface is unchanged if the function signature is the same.

Is it just pedantry? Even in the strongliest of practical strongly typed languages, two functions with the same signatures might fail to return on some inputs in the new version that it didn't in the old.

That's a practical distinction I care about that can't be computed.

Re: Be Nice and Write Stable Code

#113

Post by pjmlp »

gmueckl wrote: post #95
pjmlp wrote: post #71

Earlier quoted context omitted.

> 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.

I have the opinion that is the job of functional tests anyway.

Unit tests should only exercise public interfaces, with internals and private parts being tested as side effect of calling them.

Re: Be Nice and Write Stable Code

#114

Post by crdoconnor »

jakobegger wrote: post #96
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.

They built tests that explicitly assumed that the library's interface wasn't going to change:

>When we upgraded, all our tests passed (because our test fixtures emulated the old behavior)

Doing that, upgrading your dependencies and expecting everything to work just because those tests passed? That's naivete.

If they'd built decent integration tests that used the actual library (instead of "assume nothing changes" fixtures) and made more of an effort to simulate realistic scenarios then their tests probably would have flagged up most of the issues they had.

Alas, this seems to be one of the side effects of following the "test pyramid" "best practice".

Re: Be Nice and Write Stable Code

#116

Post by planetmaker »

It's a bit funny that the title reads "write nice and stable code" - but it's actually a plea for "proper" versioning.

Starting with the versioning a few examples are given - and I read it as "this is not good versioning" as it continues with the very basic description of how semantic versioning works. Yet all those examples given above are excellent examples of how semantic versioning works at its best! """ 10. Build metadata MAY be denoted by appending a plus sign (...) Examples: (...) 1.0.0-beta+exp.sha.5114f85. """

And these meta data, referencing used library versions and actual hash of the commit used in the build, are given there - and exactly these meta info on used library versions may help a great deal when it comes to checking bug reports as programme behaviour may differ between versions, but work with any.

Re: Be Nice and Write Stable Code

#117

Post by p2t2p »

t3soro wrote: post #109
p2t2p wrote: post #98

Earlier quoted context omitted.

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.

He means, how can a machine determine it?

Ah, you mean what to bump and when? That's easy, you make a decision to break an API so you need a major version bump. In this case you perform a customized build overriding variables in CI GUI. All other releases are automated minor bumps if on master and patch version bump if it happens on release branch which we keep around for bug fixes. Those bug fixes propagated through release branches up to the master automatically whenever you merge a PR with a bug fix.

Re: Be Nice and Write Stable Code

#118

Post by slavik81 »

kornish wrote: post #63
oweiler wrote: post #58

Earlier quoted context omitted.

And who decides if a change is breaking or not?

Probably pretty simple. Destructively making a public API change is breaking. Additively changing an API isn’t. Adding an optional public param or new symbols isn’t. Harder to detect cases in which the signature stays the same but the expected behavior changes, though (as noted in TFA).

One somewhat subtle implication is that you need to have a clearly defined expected behaviour. If people have to read your implementation to use your API, then your implementation has become the specification and basically every change will be a breaking change.

Re: Be Nice and Write Stable Code

#119

Post by gmueckl »

flukus wrote: post #67
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. This is a limitation imposed by the IDE, not the language. There's nothing stopping you from compiling code and tests into the same dll that you unit test. Likewise there is no need to separate code from the tests (apart from different files), they can simply not be included in release…

Not keeping tests separate from the tested code can lead to chaos in the long term. It provides an incentive to blur the lines in inappropriate ways, e.g. by adding helper code for tests to the code under test etc.

Re: Be Nice and Write Stable Code

#120

Post by eeZah7Ux »

moviuro wrote: post #81
sametmax wrote: post #73

Earlier quoted context omitted.

I think we should stop publishing releases. Writing code is subject to human error and could break somebody else's work.

Well, if you wrote stable code in the first place, there wouldn't indeed be any need for updates!

Jokes aside, a lot of developers would call a project "dead" when is working as intended and not receiving new commits.
Post reply on HN