<?xml version="1.0" encoding="UTF-8"?>
<mods xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.loc.gov/mods/v3" version="3.1" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-1.xsd">
  <titleInfo>
    <title>The rules of programming</title>
    <subTitle>how to write better code</subTitle>
  </titleInfo>
  <name type="personal">
    <namePart>Zimmerman, Chris</namePart>
    <role>
      <roleTerm authority="marcrelator" type="text">creator</roleTerm>
    </role>
  </name>
  <typeOfResource>text</typeOfResource>
  <originInfo>
    <issuance>monographic</issuance>
  </originInfo>
  <language>
    <languageTerm authority="iso639-2b" type="code">eng</languageTerm>
  </language>
  <physicalDescription>
    <form authority="marcform">print</form>
    <extent>xiv, 327 pages ; 23 cm.</extent>
  </physicalDescription>
  <abstract>"This philosophy-of-programming guide presents a unique and entertaining take on how to think about programming. A collection of 21 pragmatic rules, each presented in a standalone chapter, captures the essential wisdom that every freshly minted programmer needs to know and provides thought-provoking insights for more seasoned programmers"-- Provided by publisher</abstract>
  <tableOfContents>As simple as possible, but no simpler -- Bugs are contagious -- A good name is the best documentation -- Generalization takes three examples -- The first lesson of optimization is don't optimize -- Interlude: In which the previous chapter is criticized -- Code reviews are good for three reasons -- Eliminate failure cases -- Code that isn't running doesn't work -- Write collapsible code -- Localize complexity -- Is it twice as good? -- Big teams need strong conventions -- Find the pebble that started the avalanche -- Code comes in four flavors -- Pull the weeds -- Work backward from your result, not forward from your code --- Sometimes the bigger problem is easier to solve -- Let your code tell its own story -- Rework in parallel -- Do the math -- Sometimes you just need to hammer the nails -- Conclusion: Making the rules your own -- Appendix A. Reading C++ for Python programmers -- Appendix B. Reading C++ for JavaScript programmers.</tableOfContents>
  <note type="statement of responsibility">Chris Zimmerman</note>
  <note>Includes index.</note>
  <subject>
    <topic>Computer Programming</topic>
  </subject>
  <subject>
    <topic>Computer Programming</topic>
    <topic>Philosophy</topic>
  </subject>
  <classification authority="lcc">SHS QA 76.6 Z56 </classification>
  <identifier type="isbn">9781098133115</identifier>
  <recordInfo>
    <recordCreationDate encoding="marc">240427</recordCreationDate>
    <recordChangeDate encoding="iso8601">20240510134730.0</recordChangeDate>
  </recordInfo>
</mods>
