Programming Tips Tweets #1
Episode #1 of Programming Tips
Never think that formatting code or indenting is useless, it is for maintaining readability & re-usability.
TODO comment tag is good for ongoing development on daily basis but never consider leaving it for production.
Writing comments for all public methods & non-self-documenting variables is a good practice for documentation skills.
Lack of commenting will increase maintenance time. also, variable/method names should be readable and self commenting.
Unnecessary over-commenting in each line will reduce readability so use comments as required.
Don’t write incorrect comments because incorrect explanations are worse than no-comment.
The mood is to watch a movie? Go on this isn’t wasted time that you use to please yourself; Find time for yourself
To control over emails & phone calls, it might be worth making it clear that you can only reached between certain times.
Don’t delay things because you feel shy to explain that you don’t want to be disturbed for as example “couple of hours”.
Decide when you feel most productive and use this time to tackle the big tasks or to solve the unsolved problems.
Pay attention to the most important things even if so small, but don’t allow the smaller issues to delay big ones.
Project Based Learning is going through the extended process of inquiry in response to a complex question, problem, or challenge.
Check the mails/tweets/posts grammar & spelling, this is so elementary thing to do!
Never require administrator/root/sa permissions, this along with SQL concatenation causes serious security flaw.
Priorities, plan productively, never delay, clear your contact method, don’t be afraid to delegate and keep notes.
Don’t ever make a programmatic reference to a filename that include a symbolic link #symlink_vulnerability.
To learn programming faster: study example code, run it, write your own ASAP, learn to use a debugger and seek out more sources.
Make sure that sensitive data & configuration files are not stored in either code or plain text.
Make sure administration interfaces & remote administration channels are secured with strong authentication & authorization.
Minimize as possible the error information returned about the authentication failure events.
Account management policies should meet the controls logical flow and design flow.
Make sure data is validated for type, length, format, and range.
JOIN columns should have indexes of the same type because a JOIN on columns of different types may force sequential scan.
Indexes should be symmetrical, an index on several columns isn’t symmetric and doesn’t work equally on every field.
Try to use indexes to write queries that avoids sequential scans which is an evil matter sucking #database memory & CPU time.
Using client-side validation only as a security measure isn’t sensible so double check inputs in server-side scripts.
Don’t insert without escaping those DOM functions which are decoding #html entities ex. .html()
Be sure that any data sent to/by JavaScript function may be observed by a malicious user.
Because users can disable JavaScript don’t rely on it for validation.
Avoid using the /e flag as this kind of mistakes in escaping strings can lead to arbitrary code execution vulnerabilities.
Don’t use floating for monetary value because binary floating leads to inexact results.
Don’t use string if a better type exists.
Dear fellow programmer, never trust the user input or trust it at your own risk!
An alternative of using PHP5 hash extension is to apply hash function twice.
Use double (64 bits) instead of float (32 bits) because more bits equals more precision depends on how bits are allocated.
Your API is a little language so try to be consistent, regular & symmetrical because clients shouldn’t parse strings.
Avoid using generic or “system reserved” names such as “Date”, “Table”, I’ve even seen once “Variable” as a DB field name.
Make sure implementation have no (measurable) impact on the runtime performance. example: don’t specify hash functions
For good API design create your own eval() instead of language’s eval() to prevent evaluated code overwrite variables while calling.
Use name spaces because for each running script, class name must be unique and because programmers tend to add class generic names.
Good API design provides a database abstraction layer as a service provider interface & parametrized queries to avoid SQL injection.
Specialize, apply professional ethics, figure out your goals, find time to #develop yourself, find inspiration & honest critique.
Don’t force client to use exceptions for control flow!.
For the sake of better exception handling, throw exceptions to indicate exceptional conditions only!
For the sake of good #code re-usability try to reduce the need for copy-paste.
Dear #programmers, for the sake of good method design my #advice is “overload carefully”
Strong typing is the best for coding with any programming language.
For the sake of good class design, subclass only when it makes sense otherwise use composition.
For a good class design and for the sake of easy implementation, public classes shouldn’t subclass other public classes.
For the sake of code re-usability, return types and avoid obsolete parameters.
For a very good documentation, document every class, interface, method, constructor, parameter and exception.
Obey standard naming conventions.
For API code re-usability and for a very good documentation, make sure your functionality is easy to explain.
Your API should do one thing and doing it well.
For the matter of #coding API security, public classes should have no public fields except the constants.
To secure your API try to minimize the accessibility of everything, make classes & members as private as possible.
When it comes to API design try to simulate the patterns of the programming language.
Code Reuse = Good API Design + Very Good Documentation.
Code lives only as examples and unit tests, this is a fact.
