5 ms·

I honestly don't get the hate toward header files. They're not great, but are they really that bad?

by s73v3r 11y ago

pjmlp 11y ago
I guess you never used module based languages. Why write things twice when the compilers are able to export text definitions from modules and IDEs can show them as well.
- vonmoltke 11y ago
  Maybe I am misunderstanding, but I thought the point of headers is to avoid writing things twice (or more).
  - pjmlp 11y ago
    On the header file you write the function interface and class definitions. On the implementation file you have again to repeat those plus the actual implementation. On many languages with module support, you just mark whatever symbol with public, that's it.
    - vonmoltke 11y ago
      OK, you meant specifically the source/header split on classes in languages like C++. Yeah, there is definitely redundancy there that gets eliminated by headers. I also think I may have been conflating "header" with "include file" to a greater degree than is appropriate.
- s73v3r 11y ago
  I have. And while nice, I honestly don't see what's so bad about writing headers. I like being able to export a set of headers and a binary library.
  - pjmlp 11y ago
    Why write them if tools can do it automatically for us?
    - mjcohen 11y ago
      Because the tool may include more information than is needed or wanted. The tool may also not be able to detect (without being told) that some information should be included.
      - pjmlp 11y ago
        I fail to see what one can different. Public types are visible, which are the only ones that matter to the module user. Many languages with modules support public and private comments as well.
coldtea 11y ago
They're not bad. Just redundant.
- mkesper 11y ago
  And redundancy _is_ bad.
  - coldtea 11y ago
    Depends. Other times we call it "backup". Or "failover".
  - astrange 11y ago
    Redundancy is not always bad. It allows concurrent evolution in your code, specialization, and info hiding, because each copy is in a more specific context and you know just what you want from it there. Related: http://yosefk.com/blog/low-level-is-easy.html http://yosefk.com/blog/low-level-is-easy.html In Objective-C writing headers by hand gives full manual control of what your library's users get to know about your class, including comments. Internal things just don't appear in the first place. C++, of course, makes it impossible to hide anything from your users because they need to allocate your class themselves, you need to put all your private ivars and methods in the public class definition, and you can't add ivars to the class later. But that's its problem.
    - GFK_of_xmaspast 11y ago
      > C++, of course, makes it impossible to hide anything from your users because they need to allocate your class themselves, you need to put all your private ivars and methods in the public class definition, and you can't add ivars to the class later. On the other hand, actual practice: http://www.gotw.ca/gotw/024.htm http://www.gotw.ca/gotw/024.htm
      - astrange 11y ago
        Oh, but Objective-C does the right thing using the standard and simplest way to write it, and you can subclass other people's classes and everything! http://stackoverflow.com/questions/12522053/what-is-a-non-fragile-abi http://stackoverflow.com/questions/12522053/what-is-a-non-fr...
DubiousPusher 11y ago
Yes, they are. 1) They add fragility. It's all too easy to take a dependency on code without explicitly stating it. I'm using objects from "b.h" by including "a.h" which include "b.h" but I don't realize it. 2) They bring extraneous data into the code. A #include says more about the structure of your files than it may about the logical relationships between objects. Where to get things for the build is a job for the build config/system, not your business logic. 3) They're easy to use poorly. From your first circular include to the time you have to sort out a crawling build brought on by a bloated include tree, you'll swear there's gotta be a better way. They are good for some people though; there's a small cottage industry that's built around resolving the myriad irritations headers bring.

I honestly don't get the hate toward header files. They're not great, but are they really that bad?

by s73v3r 11y ago

I honestly don't get the hate toward header files. They're not great, but are they really that bad?

pjmlp 11y ago

I guess you never used module based languages. Why write things twice when the compilers are able to export text definitions from modules and IDEs can show them as well.

vonmoltke 11y ago
Maybe I am misunderstanding, but I thought the point of headers is to avoid writing things twice (or more).
- pjmlp 11y ago
  On the header file you write the function interface and class definitions. On the implementation file you have again to repeat those plus the actual implementation. On many languages with module support, you just mark whatever symbol with public, that's it.
  - vonmoltke 11y ago
    OK, you meant specifically the source/header split on classes in languages like C++. Yeah, there is definitely redundancy there that gets eliminated by headers. I also think I may have been conflating "header" with "include file" to a greater degree than is appropriate.
s73v3r 11y ago
I have. And while nice, I honestly don't see what's so bad about writing headers. I like being able to export a set of headers and a binary library.
- pjmlp 11y ago
  Why write them if tools can do it automatically for us?
  - mjcohen 11y ago
    Because the tool may include more information than is needed or wanted. The tool may also not be able to detect (without being told) that some information should be included.
    - pjmlp 11y ago
      I fail to see what one can different. Public types are visible, which are the only ones that matter to the module user. Many languages with modules support public and private comments as well.

coldtea 11y ago

They're not bad. Just redundant.

mkesper 11y ago
And redundancy _is_ bad.
- coldtea 11y ago
  Depends. Other times we call it "backup". Or "failover".
- astrange 11y ago
  Redundancy is not always bad. It allows concurrent evolution in your code, specialization, and info hiding, because each copy is in a more specific context and you know just what you want from it there. Related: http://yosefk.com/blog/low-level-is-easy.html http://yosefk.com/blog/low-level-is-easy.html In Objective-C writing headers by hand gives full manual control of what your library's users get to know about your class, including comments. Internal things just don't appear in the first place. C++, of course, makes it impossible to hide anything from your users because they need to allocate your class themselves, you need to put all your private ivars and methods in the public class definition, and you can't add ivars to the class later. But that's its problem.
  - GFK_of_xmaspast 11y ago
    > C++, of course, makes it impossible to hide anything from your users because they need to allocate your class themselves, you need to put all your private ivars and methods in the public class definition, and you can't add ivars to the class later. On the other hand, actual practice: http://www.gotw.ca/gotw/024.htm http://www.gotw.ca/gotw/024.htm
    - astrange 11y ago
      Oh, but Objective-C does the right thing using the standard and simplest way to write it, and you can subclass other people's classes and everything! http://stackoverflow.com/questions/12522053/what-is-a-non-fragile-abi http://stackoverflow.com/questions/12522053/what-is-a-non-fr...

DubiousPusher 11y ago

Yes, they are. 1) They add fragility. It's all too easy to take a dependency on code without explicitly stating it. I'm using objects from "b.h" by including "a.h" which include "b.h" but I don't realize it. 2) They bring extraneous data into the code. A #include says more about the structure of your files than it may about the logical relationships between objects. Where to get things for the build is a job for the build config/system, not your business logic. 3) They're easy to use poorly. From your first circular include to the time you have to sort out a crawling build brought on by a bloated include tree, you'll swear there's gotta be a better way. They are good for some people though; there's a small cottage industry that's built around resolving the myriad irritations headers bring.