undefined | Better HN

0 pointsgizmo6866y ago0 comments

If you are writing special cases because a 200+ page rulebook says you need them, then the special cases should be commented to indicate exactly what rule they are meant to address such that someone with the rulebook can quickly look it up.

Ideally, you would have all the rules encoded in a central place so this lookup becomes obvious from the structure of the code, but that is often not possible.

I am involved in a simmilar project now. We have a proprietary data format which has, over the years, evolved slightly different versions as different teams extended it in slightly different and incompatable ways. The code has all kinds of special cases, to the point where we developed internal style guidelines for how to comment them

0 comments

scarface746y ago

So now you have the rule book and the comments and if there is a bug in any of the code, an I suppose to remember what all the code does and think through it? Am I suppose to be able to just think through why the one set of hundreds of records that came from one of 200+ repair yards is giving back erroneous results or should I just use a debugger and set a conditional breakpoint?

bartimus6y ago

In this particular case you should probably implement some logging or alternative output that shows how the rules are being applied. Also perhaps the rules shouldn't be part of the code itself. It would be preferable to be able to add/remove/update a rule without needing to deploy a new version of the program (without going down the rabbit hole of implementing an entire logic engine).

hyperman16y ago

I once was in a situation like this: Tons of weird rules, straight from the law, which made no sense at all.

Every day someone came along with a bug. After tracing through the code for half an hour, the program was generally proven correct. The business had forgotten some weird edge case of an edge case.

I always wanted to write a small gui program that would list for the business which rules had been applied, and what all intermediate data was.

BREs were to slow, btw, so everything was hardcoded.

scarface746y ago

That’s exactly what you end up doing - writing your own rules engine instead of just using your language of choice.

How much harder is it to “deploy your whole” program than changing a complex XML/JSON configuration file or database change, testing it, and then deploying that?

In fact, it’s ususlly much easier deploying code. Setting up a simple pipeline to deploy a service is not rocket science.

1 more reply

j / k navigate · click thread line to collapse

0 pointsgizmo6866y ago0 comments

Ideally, you would have all the rules encoded in a central place so this lookup becomes obvious from the structure of the code, but that is often not possible.

0 comments

scarface746y ago

bartimus6y ago

hyperman16y ago

I once was in a situation like this: Tons of weird rules, straight from the law, which made no sense at all.

Every day someone came along with a bug. After tracing through the code for half an hour, the program was generally proven correct. The business had forgotten some weird edge case of an edge case.

I always wanted to write a small gui program that would list for the business which rules had been applied, and what all intermediate data was.

BREs were to slow, btw, so everything was hardcoded.

scarface746y ago

That’s exactly what you end up doing - writing your own rules engine instead of just using your language of choice.

How much harder is it to “deploy your whole” program than changing a complex XML/JSON configuration file or database change, testing it, and then deploying that?

In fact, it’s ususlly much easier deploying code. Setting up a simple pipeline to deploy a service is not rocket science.

1 more reply

j / k navigate · click thread line to collapse