{"id":68,"date":"2020-08-15T23:10:58","date_gmt":"2020-08-16T03:10:58","guid":{"rendered":"https:\/\/sites.nd.edu\/jonathan-takeshita\/?page_id=68"},"modified":"2022-11-08T18:24:29","modified_gmt":"2022-11-08T23:24:29","slug":"programming-tips","status":"publish","type":"page","link":"https:\/\/sites.nd.edu\/jonathan-takeshita\/programming-tips\/","title":{"rendered":"Programming Tips and Advice"},"content":{"rendered":"<p>A collection of miscellaneous programming and computer tips that I really needed at some points in the past, and probably will need again in the future.<\/p>\n<ol>\n<li>Keep it simple, stupid.\n<ul>\n<li>Program exactly what you mean, and optimize later. (But don&#8217;t write lazy slow code on the first run either!)<\/li>\n<li>Don&#8217;t use language features just because they exist (e.g., C++ templates).<\/li>\n<li>Use boring, battle-tested tools and software. People have been trying for decades to replace C and C++; don&#8217;t be a guinea pig in the latest attempt.<\/li>\n<\/ul>\n<\/li>\n<li>Use the right tool for the job, and be willing to learn new tools as the job requires. Be flexible.\n<ul>\n<li>Python is best for gluing other stuff together, and getting something up and running quickly.<\/li>\n<li>C++ can do, or be used for, pretty much anything. This is not always a good thing.<\/li>\n<\/ul>\n<\/li>\n<li>Learn C. No way around it.<\/li>\n<li>Learn the const keyword, in all its incarnations, and use it wherever possible.\n<ul>\n<li>Pass by const reference for anything significantly larger than a word (usually 64 bits).<\/li>\n<li>Declare class functions const as appropriate. If this causes a lot of compiler errors, you&#8217;re doing something wrong.<\/li>\n<\/ul>\n<\/li>\n<li>Test thoroughly. Testing is what demarcates engineering and scratch work.<\/li>\n<li>Learn the Linux toolchain and other tools. Even just a few tricks with gcc, bash, git, gdb, valgrind et al. can go a long ways. Especially git.\n<ul>\n<li>Use Linux as a daily OS &#8211; I recommend Ubuntu or Pop_OS. It&#8217;s actually easier to get things done in Ubuntu than in Windows nowadays.<\/li>\n<\/ul>\n<\/li>\n<li>Ensure a bijection exists between calls to malloc\/calloc\/new and calls to free\/delete.\n<ul>\n<li>Write the allocation, write the deallocation immediately after, then write your code in between those lines.<\/li>\n<li>Also, make sure the correct number of <em>bytes\u00a0<\/em>(hint: use sizeof) are argued to malloc\/calloc, and check the returned pointer.<\/li>\n<\/ul>\n<\/li>\n<li>Write functions to return error codes, and check those returned values.<\/li>\n<li>Use preprocessor macros to create a debug build.\n<ul>\n<li>The tougher the task, the more assertions you should have &#8211; 1:8 was the recommended ratio of assertions to lines of code for my undergraduate operating systems course.<\/li>\n<li>Also, macros are a must-know for any cross-platform programming.<\/li>\n<\/ul>\n<\/li>\n<li>Have a complete and clear specification for the project, and do not try to add in features a week before the deadline.\n<ul>\n<li>Start the project when it is assigned, and don&#8217;t procrastinate, unless you want to have a segfault you can&#8217;t figure out on the due date. This is harder for research projects where the goals and scope may frequently change.<\/li>\n<\/ul>\n<\/li>\n<li>Only keep one copy of a program installed on your system.\n<ul>\n<li>Python is the worst offender, but the 2\/3 split isn&#8217;t always easily resolved.<\/li>\n<\/ul>\n<\/li>\n<li>Never hardcode values &#8211; it makes debugging harder, and makes bugs easy. Use static const (C++) or #define (C) for constants.<\/li>\n<li>Mount your home and root directories on different disk partitions, so that you can easily switch operating systems while keeping your files.<\/li>\n<li>Keep Windows and Linux on different disks so the Windows updater can&#8217;t mess with the Linux partitions.\n<ul>\n<li>Learning to use \/etc\/fstab to manage your disks and partitions will be time very well spent.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>A collection of miscellaneous programming and computer tips that I really needed at some points in the past, and probably will need again in the future. Keep it simple, stupid. Program exactly what you mean, and optimize later. (But don&#8217;t write lazy slow code on the first run either!) Don&#8217;t use language features just because [&hellip;]<\/p>\n","protected":false},"author":3786,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-68","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/pages\/68","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/users\/3786"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/comments?post=68"}],"version-history":[{"count":35,"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/pages\/68\/revisions"}],"predecessor-version":[{"id":346,"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/pages\/68\/revisions\/346"}],"wp:attachment":[{"href":"https:\/\/sites.nd.edu\/jonathan-takeshita\/wp-json\/wp\/v2\/media?parent=68"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}