Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21741

Re: Reading a File

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Reading a File Subhabrata <subhabangalore@gmail.com> - 2013-01-25 20:58 -0800
  Re: Reading a File Knute Johnson <nospam@knutejohnson.com> - 2013-01-25 21:33 -0800
    Re: Reading a File subhabangalore@gmail.com - 2013-01-25 21:53 -0800
      Re: Reading a File Lew <lewbloch@gmail.com> - 2013-01-25 22:48 -0800
        Re: Reading a File Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 08:01 -0400
          Re: Reading a File Lew <lewbloch@gmail.com> - 2013-01-26 10:12 -0800
          Re: Reading a File Knute Johnson <nospam@knutejohnson.com> - 2013-01-26 11:41 -0800
            Re: Reading a File Lew <lewbloch@gmail.com> - 2013-01-26 13:01 -0800
  Re: Reading a File Roedy Green <see_website@mindprod.com.invalid> - 2013-01-26 02:47 -0800

csiph-web