esoxjem

Logging is used for 3 primary goals
* debugging
* tracing - understanding execution flow of the program in real life
* checking inputs

There are better tools available for all these three tasks for most usecases
Lets see each case.

Debugging - When a bug is reported the first order of business is to write a test case that fails and this failure clearly indicates that the bug is present - the code is then modified till this test passes (and no other ones fail) - no need for logging

esoxjem

class Result:
    """Represents the outcome/result of an operation. Use instead of propogating exceptions
    accross layers. Use exceptions for only exceptional cases.
    
    Attributes
    ----------
    success : bool
        A flag that is set to True if the operation was successful, False if
        the operation failed.
    value : object

esoxjem

<scheme name="esoxjem" version="5" parent_scheme="Darcula">

<!--
1. Install Input (Pragmata Pro Style) - http://input.fontbureau.com/
2. Copy `esoxjem.icls` to `~/Library/Preferences/AndroidStudio3.1/colors/`
3. Restart AS
4. Preferences > Editor > Color and Fonts > select esoxjem and press OK
-->

esoxjem

<?xml version="1.0" encoding="UTF-8"?>
<inspections version="1.0">
  <option name="myName" value="Arun" />
  <inspection_tool class="AbstractClassExtendsConcreteClass" enabled="true" level="WARNING" enabled_by_default="true" />
  <inspection_tool class="AbstractClassNeverImplemented" enabled="true" level="WARNING" enabled_by_default="true" />
  <inspection_tool class="AbstractMethodCallInConstructor" enabled="true" level="WARNING" enabled_by_default="true" />
  <inspection_tool class="AbstractMethodOverridesAbstractMethod" enabled="true" level="WARNING" enabled_by_default="true" />
  <inspection_tool class="AbstractMethodOverridesConcreteMethod" enabled="true" level="WARNING" enabled_by_default="true" />
  <inspection_tool class="AbstractMethodWithMissingImplementations" enabled="true" level="WARNING" enabled_by_default="true" />
  <inspection_tool class="AccessToNonThreadSafeStaticFieldFromInstance" enabled="true" level="WARNING" enabled_by_default="true">

esoxjem

public class SamplingInterceptor implements Interceptor
{
    @Override
    public Response intercept(Chain chain) throws IOException
    {
        Request request = chain.request();
        DeviceBandwidthSampler.getInstance().startSampling();
        Response response = chain.proceed(request);
        DeviceBandwidthSampler.getInstance().stopSampling();
        return response;

esoxjem

import android.graphics.*;
import android.net.Uri;

public class BitmapFileLoader
{
    public static Bitmap loadFromUri(Uri fileUri, float maxWidth, float maxHeight)
    {
        BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        BitmapFactory.decodeFile(fileUri.getPath(), options);

esoxjem

code design guidelines

- when designing libraries its better to leave threads out but not always
  - realize that your users may have varying threading strategies and your lib should not prescribe or assert one lest it resists reuse
  - typical novice problems
    - http://joostdevblog.blogspot.in/2015/01/what-most-young-programmers-need-to.html
      - liar variables, methods, classes
      - muddy classes
      - oversized classes
      - code in comments

esoxjem

super basic java

- braces
  - define scope
    - no masking/shadowing but new variables are welcome
      "public void kewl()
      {
          int x = 7;
          {
      	int x = 8; //Illegal masking

esoxjem

- General
  [ ] The code works
  [ ] The code is easy to understand
  [ ] Follows coding conventions
  [ ] Names are simple and if possible short
  [ ] Names are spelt correctly
  [ ] Names contain units where applicable
  [ ] Enums are used instead of int constants where applicable
  [ ] There are no usages of 'magic numbers'
  [ ] All variables are in the smallest scope possible