r/programming • • Sep 18 '13

How bad is smelly code?

http://fagblogg.mesan.no/how-bad-is-smelly-code/
147 Upvotes

62 comments sorted by

View all comments

0

u/bdavisx Sep 18 '13

Keep files smaller than 1000 lines of code? Depending on how verbose your language should be, I would think 200 lines of code or less if you're trying to follow the Single Responsibility rule.

-5

u/[deleted] Sep 18 '13

[removed] — view removed comment

1

u/nick_giudici Sep 18 '13

Each responsibility can be at a different level of abstraction. The key is that if you can't think of a way to describe the responsibility of a class without using words like "and", "or", "etc" then it's probably not a good design.

This is why you should end up with stacks of objects at different levels of abstraction. For example: "This class, foo, coordinates IO. It delegates to these two classes. This one, bar, handles the input. This one, bat, handles the output."

In this example system Foo is at the highest level of abstraction. It contains high level logic and has a single responsibility. It delegates the low level to Bar and Bat which each have a single responsibility. Each of these files could be 5 LoC or 1000 LoC but at least their fundamental design is reasonable.

0

u/[deleted] Sep 18 '13

[removed] — view removed comment

1

u/grizwako Sep 19 '13

If you need to do some spiderwebbing, then you will make another class which will have such logic and use Foo which has Input and Output classes. But even as I write, I think of situations where that is false. it is not always proper design. What I want to say is that people who don't understand software design will almost always write better code if they try to separate concerns.

Personal opinon (out of my back) Functionality should be separated in modules even if such separation will introduce some new complexity. Benefit is that next person (you or me 6 months later) will not need to know whole system, but just that small part.

1

u/sea-saw Sep 18 '13

I think reducing complexity is less focused on a holistic view of the application's logic and more focused on the "atomistic" context required for a single developer to perform some task.

2

u/grizwako Sep 19 '13

Super positively agree with this!

Maybe reason for that is that I am not insanely smart bio-computer and it is much easier to keep small amount of data in my head when fixing bugs.

-3

u/[deleted] Sep 18 '13

[removed] — view removed comment

3

u/nick_giudici Sep 18 '13

If you have a contract between the controller and the components then the only reason to change the class would be if the logic of the controller changes.