Re: Reading a File
Arved Sandstrom wrote:
Lew wrote:
subhaba...@... wrote:
Thank you Sir. It worked. Regards,Subhabrata.
Actually, no, it didn't, but the bugs are of a nature that doesn't bother you yet.
Depends on how you run it as to whether that filename actually locates
the source file.
Overall the program itself "works". main() throws an exception, which
may be acceptable for a console app. Hardcoding the filename isn't a
defect unless you have a requirement to specify variable files.
Having it in the default package ain't great, along with not using
braces for the loop I'd nominate this as a latent defect.
Excellent code review, Arved.
Gentle Reader, the purpose of code is to do a certain job. For the OP's purpose,
the program worked. As weeds are merely plants for which one doesn't have a use yet,
so working code comprises bugs for which one doesn't have a scenario yet.
So the program works because we don't yet care about bugs like "the error message on
the console is ugly" because we don't care that it's ugly until we put the program in front
of a different audience.
Ontologically is that a bug? Who cares? It only matters that it doesn't have bugs that we
care about now - however loosely we define terms.
Or do we care? Certain observations show increased likelihood that program features will
function as bugs and that this will bother us eventually, compared to a near-horizon
analysis. Namely, source code is more viral than naive expectations allow - that 'throws
IOException' will be seen as ugly by important people within the code's lifetime, like as not.
Bad habits ingrain - it becomes increasingly hard to write graceful error handling the less you
practice it. People model their practices after bad examples. Vital knowledge is missed early
in the learning process - by the time you're getting a paycheck for it, it's late to learn for
the first time how packages reduce emergent bugs.
Best practices are best practices because they deal with the far horizon - you and your code
have an impact farther in time and space than some realize. It's not over-engineering to fully
Javadoc your code, to handle all sorts of weird inputs, to log errors (using *logging*), to gracefully
absorb errors and convert them back to stable program state, to follow naming and indentation
conventions, to properly factor your code into modules and packages, to use type-safe idioms,
or to fully understand the idioms and libraries available. Not even as a beginner or in prototype
code.
Arved's code review points to the balances in the proffered code and delineates the boundaries
where its behavior begins to be describable as buggy. This is engineering - you make tradeoffs
based on the real needs of the moment without forgetting the limitations you're causing yourself.
--
Lew