iOS 开发大大们，对于这种不使用 property 的写法，是怎样看待的？是否认同？

图呢...

@lltctt 有的。

#import "KBScanMaskView.h"
#import <Masonry.h>

@interface KBScanMaskView ()
{
CAShapeLayer *_shapeLayer;
CGRect _cutoutRect;

UIView *_leftTopCorner_hor_view;
UIView *_leftTopCorner_ver_view;

UIView *_rightTopCorner_hor_view;
UIView *_rightTopCorner_ver_view;

UIView *_leftBottomCorner_hor_view;
UIView *_leftBottomCorner_ver_view;

UIView *_rightBottomCorner_hor_view;
UIView *_rightBottomCorner_ver_view;
NSMutableArray *_stripes;

UILabel *_promptLabel;

UIView *_redLine;
NSTimer *_timer;
}

@end

看变量的类型和作用~ 没感觉有啥问题~

@kera0a 不论什么类型，我都不推荐这样写， 苹果官方也没见有这种写法。

以前的代码应该都是这么写的。不过这么写有一个问题

iVar 没有什么问题啊，也许只是看着不够"Modern"吧

@a412739861 #6 怎么就发出去了…………
需要写 weak 的时候，感觉特别嗦，尤其是要调用多个实例变量的时候。

这样写如果需要调用这些变量的 set 和 get 方法就很麻烦了吧......

我是来吐槽命名的...

所以楼主认为这样有什么错呢？至少这得说清楚吧。

#10 +1

@BoBoy 阅读过很多知名开源库，都有这种写法~~

个人理解，这种变量，就是个私有变量的指针引用~ 不会有其他作用 ，不需要 get set 方法，不需要属性修饰符那些功能

如果项目强制这种格式那就服从或者说服领导从现在开始用 property 代替吧，如果不强制你可以自己用 property 格式去写。

毕竟这个也不算错，就如楼上说的不够 modern ，有得人确实比较怀旧而不愿改变，而且有得人会认为用 property 会发送 get/set message 影响性能。强制改变别人的习惯挺难的。

@kera0a “不需要属性修饰符”不准确，默认是被 `__strong` 修饰。

直接调用 _ 变量和调用 set/get 已经没有明显性能差距了吧
就算你用 property 来写，一样可以使用 _ 来调变量啊

只能说这种写法，我接盘的这个 14 年的项目，也有。。。

//
// ***AppDelegate.m
//
// Created by *** on 3/16/14.
// Copyright (c) 2014 ***. All rights reserved.
//

我是来猜功能的，二维码扫描？

对于暴露在外的我一律用 property ，私有的看情况是否需要 property ，反正我是这样写的，我看很对著名开源库都用了这种方法

老写法是这样的

内部属性我个人也是倾向于这种做法，除非有特殊需要，如支持 copy 等，对外属性一律 property 。

目前组内项目我也是建议这样写。

前两个变量和最后三个变量是后来加的把。。。

这就是原本规范的写法，这个锅不要丢给你同事，丢给苹果最合适，你去翻翻早期的源码就知道了

12 年之前的项目都这样写，你去翻翻 bat 早期的 sdk 也能看到

命名有点恶心

反正我看不惯。

没毛病， 你要适当引导他，要有方法，合作最重要的是沟通，然后达成共识，在沟通，在达成共识

以前老项目还是实例变量更多一点，向外传值才在 .h 里写 property 的。不过变量命名一直都是驼峰，这个不合规范。

全部采用 property 好像是 13 、 14 年才开始普及的，这项目老的话也没啥问题。

property 对于实例变量是有多一点点损耗的，看取决了，也并不是一定全部要用 property ，你看 FB 开源的那些项目，依然很多用实例变量。

这是个二维码扫描功能..！

纯个人习惯问题, 对于不想暴露给外部的变量, 我都是喜欢用 iVar 定义.

如果以后要把其中一些变为公有，或者要写 setter/getter ，那么就还得改成 property 了。

看见这样的代码 简直要吐， 还有，不喜欢用第三方库布局

要看是内部使用还是外部使用。如果都是内部使用的话，这样未尝不可，好处是不需要去思考 getter 和 setter 方法，清晰明了，坏处是无法用 kvo 。不过你内部变量在内部 kvo 这种设计思路本来就有问题。

要看写在哪里，在 H 文件里不支持这种写法，在 M 文件里支持这样写

在我司的项目里有些页面也有这样的写法， 也不是不可取吧，至少也是一目了然是私有变量。公司的项目迭代，主导项目的人变了，对项目的代码规范都会有影响吧。每个时期的规范不同，也不能怪谁咯。

老写法了。不过还是推荐 proproperty 。不过看见这种命名就蛋疼。

说不得是方便子类继承的私有变量了。。。 233333~

写法没有问题的，不使用 Property 自动生成 getter 和 setter 这个看个人喜好。部分命名应该要驼峰的

@game3108 请问内部变量在内部 kvo 为啥不好？